Threading in programming languages is not a new idea. Having multiple points of execution is a concept that's fundamental to any multitasking environment. Java, however, requires developers to use explicit threading to accomplish tasks as basic as reading using nonblocking I/O. This reliance on threading for simple functions has developers working with Java threads while they're still learning the language. Unfortunately, if Java is their first language, this can mean threading before they're ready. Let's look at some of the gotchas that can sneak in while using threads. Unsynchronised wait()
This is a quickie that everyone hits the first time they try to use wait. Listing A shows a wait call being made on an arbitrary object. The code compiles and will run fine right up until the wait call, at which point it will throw an IllegalMonitorStateException. Before calling the wait method on an object, you must first obtain that object's monitor by enclosing the wait call in a synchronised block. An example of this is shown in Listing B. Fortunately, this gotcha is easy to catch; the exception gives it away. Most threading errors aren't so nice and fail intermittently or deadlock silently. Let's look at a few of those next. Unsynchronised exit conditions
A common use of threads is for a looping dispatch or processor thread. These threads loop infinitely waiting for an external thread to alter the state of a mutually accessible object. However, if care is not taken to synchronise the object both threads are accessing, some subtle deadlocks can occur. In Listing C, you see a processor thread that loops until the done Boolean is set to true. It's clear that the author of the code intends for some external thread to toggle the done flag to true and have the loop exit at the end of its current iteration. But you might get tripped up with the propagation of the state of the Boolean variable, done, across thread boundaries. The Java memory model makes no guarantee that changes made to done in one thread are reflected in another. Thus, it is possible that the external thread could toggle the flag's state, but the while loop in the other thread loops forever. Seasoned developers may now be saying that they've used code just like that seen in Listing C, and it works fine. They're right; usually it works just fine. However, there's no guarantee that it will always work as expected, and every experienced developer knows how Murphy's law applies to important events and intermittent failure. The Java memory model requires that variable state be correct after a synchronisation barrier has been encountered. This can be used to eliminate the risk of an infinitely looping processor thread, as shown in Listing D. The well-read Java developer might wonder whether the volatile keyword could be used to fix the same problem. The volatile keyword was created for just this sort of situation and was intended to force memory reads when accessing stale data in case a variable was updated in another thread. Unfortunately, the Java Language Specification was insufficiently detailed when addressing the workings of volatile, and many virtual machines ignore the keyword entirely.