Detailed introduction to lock classification in Java

In many concurrent articles, I will mention various locks, such as fair locks, optimistic locks, etc. This article introduces the classification of various locks. The contents are as follows:

The above are many lock nouns. These classifications do not all refer to the state of the lock. Some refer to the characteristics of the lock and some refer to the design of the lock. The following summary is to explain the nouns of each lock.

Fair lock / unfair lock

Fair lock means that multiple threads acquire locks in the order in which they apply for locks.

An unfair lock means that multiple threads acquire locks in a different order from the order in which they apply for locks. It is possible that the thread that applies later acquires locks first than the thread that applies first. It may cause priority reversal or starvation.

For Java reentrantlock, specify whether the lock is a fair lock through the constructor. The default is a non fair lock. The advantage of non fair lock is that the throughput is greater than that of fair lock.

For synchronized, it is also an unfair lock. Unlike reentrantlock, which implements thread scheduling through AQS, there is no way to turn it into a fair lock.

Reentrant lock

Reentrant lock, also known as recursive lock, means that when the same thread obtains a lock in the outer method, it will automatically obtain the lock when entering the inner method. It's a bit abstract. Here's a code example.

For Java reentrantlock, its name can be seen as a reentrant lock, and its name is re entry lock.

For synchronized, it is also a reentrant lock. One advantage of reentrant locks is that deadlocks can be avoided to some extent.

The above code is a feature of a reentrant lock. If it is not a reentrant lock, setb may not be executed by the current thread and may cause deadlock.

Exclusive lock / shared lock

An exclusive lock means that the lock can only be held by one thread at a time.

A shared lock means that the lock can be held by multiple threads.

For Java reentrantlock, it is an exclusive lock. However, for another implementation class of lock, readwritelock, its read lock is a shared lock and its write lock is an exclusive lock.

The shared lock of read lock can ensure that concurrent reading is very efficient. The processes of reading, writing, reading and writing are mutually exclusive.

Exclusive locks and shared locks are also realized through AQS. Exclusive locks or shared locks can be realized through different methods.

For synchronized, of course, it is an exclusive lock.

Mutex / read / write lock

The exclusive lock / shared lock mentioned above is a broad term, and the mutex lock / read-write lock is a specific implementation.

The specific implementation of mutex in Java is reentrantlock

The specific implementation of read-write lock in Java is readwritelock

Optimistic lock / pessimistic lock

Optimistic locks and pessimistic locks do not refer to specific types of locks, but to the perspective of concurrent synchronization.

Pessimistic locks believe that concurrent operations on the same data must be modified. Even if they are not modified, they will be considered modified. Therefore, pessimistic locking takes the form of locking for concurrent operations of the same data. Pessimists believe that there will be problems with concurrent operations without locks.

Optimistic lock holds that concurrent operations on the same data will not be modified. When updating data, it will try to update and constantly re update the data. I am optimistic that there is nothing wrong with concurrent operations without locks.

From the above description, we can see that pessimistic locks are suitable for scenarios with many write operations and optimistic locks are suitable for scenarios with many read operations. Not locking will bring a lot of performance improvement.

The use of pessimistic locks in Java is to use various locks.

The use of optimistic lock in Java is lock free programming. CAS algorithm is often used. A typical example is atomic class, which realizes the update of atomic operation through CAS spin.

Sectional lock

Segmented lock is actually a lock design, not a specific lock. For concurrenthashmap, its concurrent implementation is to realize efficient concurrent operation in the form of segmented lock.

Let's use concurrenthashmap to explain the meaning and design idea of segment lock. The segment lock in concurrenthashmap is called segment, which is similar to the structure of HashMap (the implementation of HashMap in JDK7 and jdk8), that is, it has an entry array, and each element in the array is a linked list; at the same time, it is also a reentrantlock (segment inherits reentrantlock).

When the put element is needed, it is not to lock the entire HashMap, but to know which segment it is to be placed in through the hashcode, and then lock this segment. Therefore, when multi-threaded put, as long as it is not placed in a segment, true parallel insertion is realized.

However, when calculating size, you need to obtain all segment locks to obtain HashMap global information.

The design purpose of segmented lock is to refine the granularity of lock. When the operation does not need to update the whole array, only one item in the array is locked.

Bias lock / lightweight lock / heavyweight lock

These three locks refer to the state of the lock and are for synchronized. In Java 5, the mechanism of lock upgrade is introduced to realize efficient synchronized. The status of these three locks is indicated by the fields in the object header of the object monitor.

Biased lock means that a piece of synchronous code has been accessed by a thread, and the thread will automatically obtain the lock. Reduce the cost of obtaining locks.

Lightweight lock means that when a lock is a biased lock and is accessed by another thread, the biased lock will be upgraded to a lightweight lock. Other threads will try to obtain the lock in the form of spin without blocking and improving performance.

Heavyweight lock means that when the lock is a lightweight lock, although another thread spins, the spin will not continue all the time. When it spins a certain number of times, it will enter blocking before it has obtained the lock, and the lock will expand into a heavyweight lock. The heavyweight lock will block the threads of other applications and reduce the performance.

Spin lock

In Java, spin lock means that the thread trying to obtain the lock will not block immediately, but will try to obtain the lock in a loop. This has the advantage of reducing the consumption of thread context switching, but the disadvantage is that the loop will consume CPU.

Spin lock is realized by making the current thread execute in the loop body continuously. When the conditions of the loop are changed by other threads, it can enter the critical area. as follows

CAS atomic operation is used. The lock function sets the owner as the current thread and predicts that the original value is null. The unlock function sets the owner to null and the predicted value is the current thread.

When the second thread calls the lock operation, because the owner value is not empty, the loop will be executed until the first thread calls the unlock function to set the owner to null, and the second thread can enter the critical area.

Because the spin lock just keeps the current thread executing the loop body without changing the thread state, the response speed is faster. However, when the number of threads keeps increasing, the performance decreases significantly, because each thread needs to execute and occupies CPU time. If the thread competition is not fierce, and the lock is maintained for a period of time. Suitable for spin lock.

Note: this example is an unfair lock. The order of obtaining the lock will not be in the order of entering the lock.

The above is the whole content of this article. I hope it will be helpful to your study, and I hope you can support programming tips.