I recently had a deadlock occur that shouldn't have. One thread, the "receiver thread", waited for packets from the network, then updated an Observable object, one of whose Observers was a Component that displayed the contents of that Observable object. Unfortunately, the current implementation of Observable locks the Observable's monitor for the duration of the update; I've already submitted a bug report against it. This thread stops when it tries to update the screen via Container.validate() (since it also changes the format of things on the screen on most updates). The routine validate() is synchronized.

The second thread was the "AWT-Motif" thread, which handles events. The deadlock would occur for a variety of different events. The ones I know about for sure are closing the window and resizing the window. These cause an event to be sent to the Frame. For closing, my event handler would call Frame.dispose(); for resizing, the Frame.reshape() routine is called automatically. Both of these routines lock the Frame's monitor. dispose() in turns causes removeNotify() to get called for all the Components in the Frame. I overrode my removeNotify() method so that it would remove my Observers, which is where the thread stops, since it needs ownership of the Observable's monitor to remove an Observer.

The deadlock occurs when data comes in and needs to be shown while the user is closing or resizing the window. I found that this happened quite frequently, since a lot of data was coming in and closes and resizes are slow. One monitor is the Observable's; the other is the Frame's.