The underlying principle of Java lock-synchronized

Locks in Java can be divided into implicit locks and explicit locks. The locks of the Lock interface are all explicit locks. The JVM built-in lock is an implicit lock, and synchronized is an implicit lock.

Display lock: need to manually release the lock, you can set whether it is a fair lock

 

Implicit lock: no need to manually release the lock, unfair lock

 

Monitor

The bottom layer of the lock implemented by the Lock interface is implemented through the AQS synchronization queue. The unsafe.park() method is used. There is a monitor at the bottom of synchronized that will monitor the object holding the lock. As shown below:


       

monitorenter表示当前程序将进入同步块monitorexit表示即将退出同步块,并且释放锁

So how does the JVM know if my current object is locked?

synchronized (object) {
    //代码逻辑
}

 

As shown in the above figure, the Monitor calls the Enter method to enter the monitoring area. It will monitor whether there is a lock mark in the object. If there is no lock mark in the object, it will add the lock mark to the object and execute the following logic. Finally, release the lock and cancel the lock mark of the object. Monitor.Exit exits the monitoring area and releases the lock.

After entering the lock Monitor.Enter, it is found that there is a lock mark on the object, then the return to Monitor.Enter fails, and the Monitor is exited. Retry again afterwards.

 

Object header

The lock mark is stored in the Mark Word in the object header (class information in the method area).

 

Lock upgrade

Due to the optimization of JDK, there is an upgrade of synchronized locks, which greatly improves the performance of locks.

 

When the lock object is first created, there is no lock in the object header, when the first thread comes in. The lock is upgraded to a biased lock; when the second thread comes in, it is upgraded to a lightweight lock; the third thread comes in and waits for the lock, and the fourth and fifth threads come in and wait for the lock. When there are more threads competing, the lock will be upgraded to a heavyweight lock.

 

no lock

 

When there is no lock state, the mark bit of Mark Word is 01, and whether it is biased is marked as 0.

Bias lock

 

Whether the bias is marked as 1.

 

Lightweight lock

 

Lock flag

 

Heavyweight lock

When upgrading to a heavyweight lock, the thread will switch from user mode to kernel mode. Therefore, when a large number of threads grab the lock, the performance is not very good. It is recommended to use the lock implemented by the Lock interface.

Note that the above two types of locks are stand-alone locks. The current system is distributed and requires distributed locks. It can be achieved with zookeeper or redis. There are already mature distributed lock frameworks on the market. Like Redisson, Curator, etc. are very good.

 

Lock 与synchronized

(1) Synchronized will not cause deadlock; Lock may cause deadlock, and Lock can wait.

(2) The thread of the lock responds to the interrupt, but synchronized does not work. 

(3) Lock can know whether the lock has been successfully acquired, but synchronized can't do it.

(4) Lock can improve the efficiency of read operations by multiple threads.

(5) In terms of performance, the competition is not fierce and the two are similar; when it is very fierce (that is, there are a large number of threads competing at the same time) Lock is far superior to synchronized. Therefore, it should be selected according to the appropriate situation in specific use.

 

Guess you like

Origin blog.csdn.net/wujialv/article/details/108414870