— Scott McNealy, Sun Microsystems Chairman, President and ceo

516
 
chapter 15
The deadly side of synchronization
Be careful when you use synchronized code, because nothing 
will bring your program to its knees like thread deadlock. 
Thread deadlock happens when you have two threads, both of 
which are holding a key the other thread wants. There’s no way 
out of this scenario, so the two threads will simply sit and wait. 
And wait. And wait.
If you’re familiar with databases or other application servers, 
you might recognize the problem; databases often have a 
locking mechanism somewhat like synchronization. But a 
real transaction management system can sometimes deal with 
deadlock. It might assume, for example, that deadlock might 
have occurred when two transactions are taking too long to 
complete. But unlike Java, the application server can do a 
“transaction rollback” that returns the state of the rolled-back 
transaction to where it was before the transaction (the atomic 
part) began. 
Java has no mechanism to handle deadlock. It won’t even know 
deadlock occurred. So it’s up to you to design carefully. If you 
find yourself writing much multithreaded code, you might 
want to study “Java Threads” by Scott Oaks and Henry Wong 
for design tips on avoiding deadlock. One of the most common 
tips is to pay attention to the order in which your threads are 
started.
A simple deadlock scenario:
A
Thread A enters a 
synchronized method 
of object 
foo
, and gets 
the key. 
Thread A goes to 
sleep, holding the 
foo
key.
B
Thread B enters a 
synchronized method 
of object 
bar
, and gets 
the key.
Thread B tries to enter 
a synchronized method 
of object 
foo
, but can’t 
get 
that 
key (because 
A has it). B goes 
to the waiting lounge, 
until the
 foo
key is 
available. B keeps the 
bar
key.