Calling a synchronized block from another synchronized block with same lock

Question

I have this class:

public class MyClass {

    public MyClass(){}

    public void actionA(){
        synchronized(MyClass.class){
            System.out.print("A");
        }
    }

    public void actionB(){
        synchronized(MyClass.class){
            actionA();
        }
    }

}

Which one (if any) is true?

Calling actionB() will lead to a deadlock, since actionA() can never aquire the lock associated with MyClass.class
Calling actionB() will not lead to a deadlock, since it already has aquired the lock associated with MyClass.class

#2 is the answer. A thread is allowed to synchronize on a lock it already owns. — Gray, May 18 '12 at 12:51
possible duplicate of [Does a Deadlock Occur in This Case?](http://stackoverflow.com/questions/3679736/does-a-deadlock-occur-in-this-case) — Sergey Kalinichenko, May 18 '12 at 12:53
Duplicate of http://stackoverflow.com/questions/4883742/nested-synchronized-keyword — Santosh, May 18 '12 at 12:54
It is a duplicate indeed. It seems i didn't use the right keywords when searching for the answer, sorry. — cdriver, May 18 '12 at 14:05

Rich O'Kelly · Accepted Answer · 2012-05-18T13:02:48.143

2

#2 will happen, since the calling thread has the lock.

If however the code looked like this:

public void actionB(){
    synchronized(MyClass.class) {
      Thread thread = new Thread(new Runnable { run() { actionA(); }});
      thread.start();
      thread.join();
    }
}

Then you would have a deadlock. locks are acquired on a per thread basis.

I find a useful mental picture is of a shared key for a padlock. Only one thread can have the key at a time, but obviously the same key will open any lock which it fits (the key fits any lock that uses the same sync object).

As an aside, it is bad practice to synchronize on any publicly visible field, since another piece of code far removed could feasibly lock on the same object leading to unnecessary contention and possibly deadlocks.

edited May 18 '12 at 13:02

answered May 18 '12 at 12:51

Rich O'Kelly

41,274
9
83
114

synchronized is not just a lock . if already aquireed by the thread , it just continues. it's also easy to test the code you've written and see it for yourself. same goes to ReentrantLock – android developer May 18 '12 at 14:02
I'll check this answer as correct as rich.okelly answered first. – cdriver May 18 '12 at 14:06

score 2 · Answer 2 · answered May 18 '12 at 12:54

#2 will be happen.

Reentrant Synchronization

Recall that a thread cannot acquire a lock owned by another thread. But a thread can acquire a lock that it already owns. Allowing a thread to acquire the same lock more than once enables reentrant synchronization. This describes a situation where synchronized code, directly or indirectly, invokes a method that also contains synchronized code, and both sets of code use the same lock. Without reentrant synchronization, synchronized code would have to take many additional precautions to avoid having a thread cause itself to block.

Actually, it is simple now that i think about it. It seems i was confused as i wasn't sure who is waiting for the lock - it is the thread, not the calling block. — cdriver, May 18 '12 at 14:09

Calling a synchronized block from another synchronized block with same lock

2 Answers2