I saw this in one of Heinz Kabutz\'s Java Specialist newsletter editions and, although the rest (and indeed, all) of Dr. Kabutz\'s articles are well-explained and d
There are 2 possible issues that one would have to watch out for
Nested locks can result in deadlocks quite easily if one is using wait/notify. Here is an explanation of why. http://tutorials.jenkov.com/java-concurrency/nested-monitor-lockout.html
One should be wary that if another method wishes to lock the same two objects, they must always do it in the same order, otherwise there is the possibility of another deadlock situation as explained in this post: How to avoid Nested synchronization and the resulting deadlock
According to Nested Monitor Lockout Tutorial
In nested monitor lockout, Thread 1 is holding a lock A, and waits for a signal from Thread 2. Thread 2 needs the lock A to send the signal to Thread 1. While in deadlock, two threads are waiting for each other to release locks.
Deadlock might be analogous to two persons are imprisoned in two rooms, they want to make a switch to the other's room but both of them only have their counterpart's key. While nested monitor lockout just like the boss is arranged to sleep in a room and suppose he'll be waked up only when someone comes in the room. And the secretary is responsible for waking up his boss. But the boss still hold the key to the room when slept, so the secretary could not come in to wake him up.
On its own this code snippet won't cause any problem. But the problem may come in the form of deadlock if there is something like this code; where we have two methods with synchronized blocks in such a way that objects are locked in opposite orders-
public void doSomething() {
synchronized(lock1) {
synchronized(lock2) {
// ...
}
}
}
public void doOtherthing() {
synchronized(lock2) {
synchronized(lock1) {
// ...
}
}
}
now if more than one thread are trying to access these methods then there may be a deadlock because of nested synchronized blocks.