| What: | Secrets of Java Concurrency |
| Who: | - Heinz Kabutz |
| When: | October 20, 2009 6:00 PM |
| Where: | Sun Midtown Office - 101 Park Ave 4th Floor New York NY 10178 - GoogleMap |
| Description: | From the first version of Java, we have been able to create multiple threads. Initially, this was mostly used for making our GUIs more responsive. For example, we would read a file using a separate thread from the main Swing thread, updating the GUI as to the progress. Running many active threads on one CPU seldom made the program faster, on the contrary, the swapping overhead frequently bogged down the machine. However, in the last few years, the speed increase of CPUs has not been the clock speed, but the number of cores on each chip. We are in a position now where we can get a job done much faster by splitting it between multiple threads. Unfortunately there is still a lack of understanding of the mysteries surrounding threading. This has caused programmers to write code that is fundamentally incorrect, not taking into account best practices for threading. In this talk, we look at ten laws that can help us to write more correct threaded code: 1. The Law of the Sabotaged Doorbell We show how to manage the InterruptedException. Since they are thrown by several methods in Java 5, this is useful to know. 2. The Law of the Distracted Spearfisherman When analyzing threading problems, we should know what every thread is doing. If we gloss over one thread without understanding it, we can easily miss a problem. 3. The Law of the Overstocked Haberdashery Threads use up resources, even if they are not active, putting an upper limit on the number of threads in our system. 4. The Law of the Blind Spot Fields can be cached locally by threads to improve the performance of retrieving their value. Thus, if one thread modifies a field, the other threads might not see the updated value. 5. The Law of the Leaked Memo The Java Memory Model allows the hotspot compiler to reorder statements, as long as the final result is still correct. This can lead to some results which seem logically impossible. 6. The Law of the Corrupt Politician Data races can cause the best objects to become corrupt. They can be really difficult to detect and analyse. In this law, we look at how we can avoid these problems. 7. The Law of the Micromanager Adding synchronization to our code can cause problems with contention, where threads are waiting for each other to execute a critical section. 8. The Law of Cretan Driving The rules of the road for Java threading are quite strict, but not enforced by all of the Java Virtual Machines. Even though your code seems correct, it might still be wrong. 9. The Law of Sudden Riches Sometimes a system has latent defects that are only seen every few months. When running the system on faster hardware, these defects are amplified and can happen more frequently. 10. The Law of the Uneaten Lutefisk It is often possible to detect deadlocks in Java, but unfortunately it is impossible to recover cleanly. The only option is to analyze the problem that caused it and then restart the JVM. |