Synchronization can lead to another possible problem with your code: deadlock. Deadlock occurs when two threads each need exclusive access to the same set of resources, but each thread possesses a different subset of those resources. If neither thread is willing to give up the resources it has, both threads will come to an indefinite halt. This can bring your program to a halt. This isn’t quite a hang in the classical sense, because the program is still active and behaving normally from the perspective of the OS, but to a user the difference is insignificant.

To return to the library example, deadlock is what occurs when Jack and Jill are each writing a term paper on Thomas Jefferson and each needs the two books Thomas Jefferson and Sally Hemings: An American Controversy and Sally Hemings and Thomas Jefferson: History, Memory and Civic Culture. If Jill has checked out the first book, while Jack has checked out the second, then neither can finish the paper. Eventually the deadline expires, and they both get an F. That’s the problem of deadlock.

Worse yet, deadlock can be a sporadic and hard-to-detect bug. Deadlock closely depends on unpredictable issues of timing. Most of the time, either Jack or Jill will get to the library first and get both books. In this case, the one who gets the books writes his paper and returns the books; then the other one gets the books and writes her paper. Only rarely will they arrive at the same time and each get one of the two books. Ninety-nine times out of 100 or 999 times out of 1,000, a program may run to completion perfectly normally. Only rarely will it hang for no apparent reason. Of course, if a multithreaded server is handling hundreds or thousands of connections a minute, then even a problem that occurs only once every million requests can hang the server in short order.

The most important technique to prevent deadlock is to avoid unnecessary synchronization. If there’s an alternative approach for ensuring thread safety, such as using immutable objects or a local copy of an object, then use that. Synchronization should be a last resort for ensuring thread safety. If you do need to synchronize, keep your synchronized blocks small and try not to synchronize on more than one object at a time. This can be tricky though because many of the methods from the Java class library that your code may invoke synchronize on objects you aren’t aware of. Consequently, you may in fact be synchronizing on many more objects than you expect.

The best you can do in the general case is carefully consider whether deadlock is likely to be a problem and architect your code around it. If multiple objects need the same set of shared resources to operate, then make sure they request them in the same order. For instance, if Class A and Class B both need exclusive access to Object X and Object Y, then make sure that both classes request X first and Y second. If neither requests Y unless it already possesses X, then deadlock is not a problem.