CODEWITHSUNDEEP
javamultithreadingsynchronizationlocking
Akshay Naik
Akshay Naik

Reputation: 697

How does multiple threads acquire and release lock in synchronized methods and synchronized blocks in java?

How does the java thread acquire a lock on a monitor used in synchronized block or monitor used in synchronized methods?

I read on multiple posts that in case of biased locking this information is stored in the object header using CAS operation and in case of contended situation wait set queue/ monitor queue is used but eventually lock marked in the object header only. If this is the case then how is lock released? How object is marked free for acquiring a lock by another thread? are wait and notify methods used internally for this? If this is the case then why is making monitor null inside the synchronized block does not throw any exception.

The below example works perfectly fine, I was expecting NullPointerException assuming the end of the synchronized block will try to mark lock property to free the lock.

Example:

Object monitor = new Object();
    synchronized (monitor){
        System.out.println("before null");
        monitor =null;
        System.out.println("after null");
    }

    System.out.println("successfully Exited");

Upvotes: 2

Views: 665

Answers (1)

pveentjer
pveentjer

Reputation: 11317

In case of biased locking: if the lock is biased towards a certain thread, no CAS is needed; just a volatile write. Biased lock information is kept in the mark word of the object header. Biased locking is going to be removed from JDK 15.

If a lock is contended, the object-monitor is used for synchronization. By default the object monitor is deflated, but if there is contention or you do a wait/notify, then the monitor gets inflated and is attached to the object.

On Linux blocking behavior is implemented using a wait-queue. So when a thread needs to wait for a lock, it is removed from the scheduler and added to the wait queue. When a lock unlocks, the thread on the wait queue is reinserted back into the scheduler.

The reason why the code doesn't throw an exception is that the monitor is read only once when the synchronized block is entered.

PS: It could be that your lock get completely removed due to lock elision. If the JIT can provide no other thread can acquire that lock, there is no point in synchronizing.

Upvotes: 3

Related Questions