Heinz is the mastermind behind The Java Specialists' Newsletter. He has a PhD in Computer Science. Heinz has programmed significant portions of several large Java applications and has taught Java to thousands of professional programmers. He is a regular speaker at all the major Java conferences. Heinz was chosen as a Java Champion by Sun Microsystems, the inventors of Java, for his work in advancing Java. Heinz presents our Java training courses anywhere in the world, either in person or via remote teaching technologies. He is the author of all our courses, including Java Specialist Master, Design Patterns and Concurrency Specialist Courses.
One of the hazards of multithreaded code is that if we are not careful, we might cause a deadlock in our program. The simplest of these is the “deadly embrace,” in which locks are acquired by multiple threads in different orders. The simple deadlocks can be detected automatically with the deadlock detection tool in the ThreadMXBean. However, there are also other types of deadlocks that cannot be detected automatically and that require analysis of the stack traces of all the threads, just as in the good old days.
This hands-on-lab explains what causes deadlocks and how to find them. You will then be given a body of code to test for deadlocks, using the techniques learned.
In Java 7, the Phaser was introduced to give us a more flexible form of CountDownLatch and CyclicBarrier. In this presentation, we will show examples of how Phaser can be used to communicate between threads and how it simplifies your code. A new construct that is being worked on is the StampedLock. This new type of locking mechanism allows readers to access state concurrently, much like the ReadWriteLock. However, it is much more efficient for readers, since you can do so in a more optimistic fashion.
In this presentation, we will show how to use it and what some of the common coding patterns are that we can use.
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.