Java Network Programming (3rd ed) [Electronic resources] نسخه متنی

5.4 Deadlock

Synchronization
can lead to another possible problem: deadlock.
Deadlock occurs when two threads need exclusive access to the same
set of resources and each thread holds the lock on a different subset
of those resources. If neither thread is willing to give up the
resources it has, both threads come to an indefinite 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 they
both need 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 and Jack has checked out the
second, and neither is willing to give up the book they have, 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, hard-to-detect bug. Deadlock
usually 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 a paper and returns
the books; then the other one gets the books and writes their paper.
Only rarely will they arrive at the same time and each get one of the
two books. 99 times out of 100 or 999 times out of 1,000, a program
will 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, even a
problem that occurs only once every million requests can hang the
server in short order.

The most important technique for preventing deadlock is to avoid
unnecessary synchronization. If there's an
alternative approach for ensuring thread safety, such as making
objects immutable or keeping a local copy of an object, use it.
Synchronization should be a last resort for ensuring thread safety.
If you do need to synchronize, keep the 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 design your code around it. If
multiple objects need the same set of shared resources to operate,
make sure they request them in the same order. For instance, if Class
A and Class B need exclusive access to Object X and Object Y, make
sure that both classes request X first and Y second. If neither
requests Y unless it already possesses X, deadlock is not a problem.