Synchronized VS Lock

1. The usage difference between synchronized and lock

synchronized: Add this control to the object that needs to be synchronized. Synchronized can be added to the method or in a specific code block. The parentheses indicate the object that needs to be locked.

lock: Generally use the ReentrantLock class as a lock. The lock and unlock points need to be pointed out through the lock() and unlock() display. Therefore, unlock() is usually written in the finally block to prevent deadlock.

2. The performance difference between synchronized and lock

Synchronized is managed by the JVM for execution, and lock is the code that controls the lock written in java.

In Java 1.5, synchronize is inefficient. Because this is a heavyweight operation, the operation interface needs to be called, which may lead to the possibility that locking consumes more system time than operations other than locking. In contrast, using the Lock object provided by Java has higher performance.

But with Java 1.6, changes have taken place. Synchronize is very clear in semantics and can be optimized a lot, including adaptive spin, lock elimination, lock coarsening, lightweight locks, biased locks, and so on. As a result, the performance of synchronize on Java 1.6 is not worse than that of Lock. Officials also said that they also support synchronize more, and there is room for optimization in future versions.

The specific difference between the two mechanisms: 


Synchronized originally used the CPU pessimistic locking mechanism, that is, the thread obtained an exclusive lock. Exclusive lock means that other threads can only rely on blocking to wait for the thread to release the lock. When the CPU conversion thread is blocked, it will cause thread context switching. When there are many threads competing for locks, it will cause frequent context switching of the CPU, resulting in low efficiency.

And Lock uses an optimistic lock method. The so-called optimistic lock is to complete an operation without locking each time but assuming that there is no conflict. If it fails because of the conflict, it will retry until it succeeds. The mechanism for optimistic locking is the CAS operation (Compare and Swap). We can further study the source code of ReentrantLock, and we will find that one of the more important methods to obtain locks is compareAndSetState. This is actually a special instruction provided by the called CPU.

Modern CPUs provide instructions that can automatically update shared data, and can detect interference from other threads, and compareAndSet() uses these instead of locking. This algorithm is called a non-blocking algorithm, which means that the failure or suspension of one thread should not affect the failure or suspension of other threads.

3. The difference between synchronized and lock usage


There is no difference between synchronized primitive and ReentrantLock in general, but in very complex synchronization applications, please consider using ReentrantLock, especially when you encounter the following types of requirements.

1. A thread needs to be interrupted while waiting for the control of a lock. 
2. Some wait-notify needs to be processed separately. The Condition application in ReentrantLock can control which thread to notify 
. 3. With a fair lock function, each incoming Threads will be queued up

to sum up

Similarities and differences between synchronized and ReentrantLock

ReentrantLock supports a non-blocking way to acquire locks and can respond to interrupts, while synchronized does not work.
ReentrantLock must manually acquire and release the lock, while synchronized does not require
ReentrantLock to be a fair lock or unfair lock, while synchronized can only be an unfair lock
. At that time, the lock held by the thread will be automatically released, and when ReentrantLock is abnormal, if the unlock is not used to release the lock, it is likely to cause a deadlock. Therefore, it is necessary to release the lock in the finally block.
Both synchronized and ReentrantLock are reentrant locks.
 

Guess you like

Origin blog.csdn.net/qq_27828675/article/details/115372519