Shulou(Shulou.com)06/02 Report--

This article mainly explains "what are the locks in JUC concurrent programming". The content in the article is simple and clear, and it is easy to learn and understand. Please follow the editor's train of thought to study and learn what locks are in JUC concurrent programming.

When multiple threads access an object, without considering the scheduling and alternating execution of these threads in the running environment, there is no need for additional synchronization, or any other coordinated operation on the caller, the behavior of calling this object can get the correct result, then the object is thread-safe. But this is not the case, so JVM implements the locking mechanism, and today there are all kinds of locks in JAVA.

1. Spin lock and adaptive lock

Spin lock: the lock state of shared data only lasts for a short period of time in the state of multithreaded competition. It is not worth suspending and resuming the blocked thread for this period of time. Instead, let the thread that did not acquire the lock spin (spin does not give up the CPU fragmentation time) and wait for the current thread to release the lock. If the spin exceeds the limited number of times, the lock is not successfully acquired. You should hang the thread in the traditional way. In the JDK definition, the default spin lock is 10 spins, which the user can change using the parameter-XX:PreBlockSpin (spin lock is turned on by default after jdk1.6).

Adaptive locks: in order to solve some special cases, if the thread releases the lock as soon as the spin ends, isn't it a bit uneconomical? The adaptive spin lock is introduced by jdk1.6, which stipulates that the spin time is no longer fixed, but is determined by the spin time of the previous time on the same lock and the state of the lock owner. If, on the same lock object, spin wait has just successfully acquired the lock, and the thread holding the lock is running, JVM will think that the thread has a good chance of spin acquiring the lock and will automatically increase the wait time. On the contrary, they think that it is not easy to get the lock and give up spinning.

Lock elimination: lock elimination means that the virtual machine just-in-time compiler requires synchronization on some code at run time, but locks that are detected to be impossible to compete for shared data are eliminated. Meaning: in a piece of code, all the data on the heap does not escape and is accessed by other threads, so you can treat them as data on the stack, thinking that they are private to the thread and do not need to be locked.

Lock coarsening:

Public static void main (String [] args) {StringBuffer buffer = new StringBuffer (); buffer.append ("a"); buffer.append ("b"); buffer.append ("c"); System.out.println ("the result after splicing is: >" + buffer);} @ Override @ IntrinsicCandidate public synchronized StringBuffer append (String str) {toStringCache = null; super.append (str) Return this;}

StringBuffer is synchronized when concatenating strings. However, the same object (StringBuffer) is locked and unlocked repeatedly in a series of operations. Frequent locking and unlocking operations will lead to unnecessary performance loss. JVM will extend the scope of locking synchronization to the outside of the whole operation, adding locks only once.

2. Lightweight lock and heavy lock

The implementation of this lock is based on the assumption that most of the synchronization code in our program is generally in a lock-free competition state (that is, a single-threaded execution environment). In the case of no lock competition, we can avoid calling the heavyweight mutex at the operating system level, instead, we only need to rely on a CAS atomic instruction to acquire and release the lock in monitorenter and monitorexit. Lightweight locks are relative to heavyweight locks.

Lightweight locking process

The object header of the HotSpot virtual machine is divided into two parts, one is used to store the runtime data of the object itself, such as Hashcode, GC generational age, flag bits, and so on. The length of this part is 32bit and 64bit in 32-bit and 64-bit virtual machines, respectively, called Mark Word. The other part is used to store pointers to the method area object type data, and if it is an array object, there is an additional part to store the array length.

Object header information is an additional storage cost independent of the data defined by the object itself. Mark Word is designed as a non-fixed data structure to store as much information as possible in a very small space. There are two bit storage lock tag bits in mark word.

HotSpot virtual machine object header Mark Word

Storage content flag bit status object hash code, generational age 01 unlocked pointer to lock record 00 lightweight lock pointer to heavyweight lock 10 inflated heavyweight lock null, no recording information 11GC flag biased towards thread id, biased towards timestamp, object generational age 01 can be biased

When the code enters the synchronous code block, if the object is not locked (marked with a state of 01), the virtual machine first establishes a space called lock record (Lock Record) on the stack frame of the current thread, which is used to store a copy of the current Mark Word of the lock object, and then the virtual machine uses the CAS operation to attempt to update the object's Mark Word to a pointer to the Lock Record. If the operation is successful, then the thread has a lock on the object. And change the tag bit of Mark Word to 00, indicating that the object is in a lightweight locked state. If the update fails, the virtual machine first checks to see if the current thread owns the lock for this object, and if so, enters the synchronization code, and if not, the lock is occupied by another thread. If there are more than two threads competing for the same lock, the lightweight lock is no longer valid. To expand to a heavy lock, the lock mark bit changes to 10, and the waiting thread will enter the blocking state.

Lightweight lock unlocking process

The unlocking process is also carried out using the CAS operation, and the CAS operation is used to release the Mark Word to the Lock Record pointer. If the operation is successful, then the whole synchronization process is completed. If the release fails, it means that another thread is trying to acquire the lock, then wake up the suspended thread while releasing the lock.

3. Bias lock

The JVM parameter-XX:-UseBiasedLocking disables biased locks;-XX:+UseBiasedLocking enables biased locks.

Bias locks are not performed until bias locks are enabled. When the lock object is first acquired by the thread, the virtual machine sets the flag bit in the object header to 01, which is biased towards mode. At the same time, use the CAS operation to get the thread ID of the current thread and store it in the Mark Word. If the operation is successful, then each time the thread holding the bias lock enters the lock-related synchronization block, it does not need any operation and goes directly. If multiple threads try to acquire the lock, the biased lock is declared invalid, and then the bias is reversed or restored to unlocked. Then it expands to a weight lock, and the mark bit status changes to 10.

4. Reentrant locks and non-reentrant locks

A reentrant lock means that after one thread acquires the lock, the lock is needed in another block of code, so the lock can be used directly without having to reacquire it. Most locks are reentrant locks. But the CAS spin lock is not reentrant.

Package com.xiaojie.juc.thread.lock;import java.util.concurrent.ExecutorService;import java.util.concurrent.Executors;/** * @ author xiaojie * @ version 1.0 * @ description: test lock reentrancy * @ date 22:09 on 2021-12-30 * / public class Test01 {public synchronized void a () {System.out.println (Thread.currentThread (). GetName () + "run a method"); b () } private synchronized void b () {try {Thread.sleep (1000);} catch (InterruptedException e) {e.printStackTrace ();} System.out.println (Thread.currentThread (). GetName () + "run b method");} public static void main (String [] args) {Test01 test01 = new Test01 () ExecutorService executorService = Executors.newFixedThreadPool (3); for (int iTuno test01.a ());} 5, pessimistic and optimistic locks

Pessimistic locks are always pessimistic, always thinking that there will be security problems, so locks will be added every time. For example, exclusive lock, row lock in traditional database, table lock, read lock, write lock and so on. Pessimistic locks have the following disadvantages:

In multithreaded competition, locking and releasing locks will lead to more context switching and scheduling delays, resulting in performance problems.

After one thread holds the lock, other threads have to block waiting.

If a high-priority thread waits for a low-priority thread, it will lead to thread priority, which may lead to performance risks.

Optimistic locks are always optimistic, always thinking that there will be no security problems. Optimistic locking can be implemented with version numbers in the database, and CAS and some atomic classes in JAVA are optimistic locking ideas.

6. Fair lock and unfair lock

Fair lock: when multiple threads are waiting for the same lock, they must acquire the lock in turn according to the time order in which they apply for the lock.

Unfair lock: the unfair lock does not need to be acquired according to the chronological order in which the lock is applied, but will be executed first by the one who can get the time slice of CPU. The advantage of unfair lock is that the throughput is larger than fair lock, and the disadvantage is that it may lead to thread priority inversion or thread hunger (that is, some threads have been executing tasks all the time, and some threads have not performed a task until death).

The lock in synchronized is an unfair lock, and ReentrantLock is also an unfair lock by default, but can be set to a fair lock by constructor.

7. Shared lock and exclusive lock

A shared lock is a lock that allows multiple threads to hold at the same time. For example, Semaphore (semaphore), ReentrantReadWriteLock read lock, CountDownLatch reciprocal latch and so on.

Exclusive lock is also called exclusive lock, mutex lock, exclusive lock means that the lock can only be held by one thread at a time. For example, synchronized built-in locks and ReentrantLock display locks, ReentrantReadWriteLock write locks are exclusive locks.

Package com.xiaojie.juc.thread.lock;import java.util.concurrent.locks.ReentrantReadWriteLock;/** * @ description: read-write locks verify shared and exclusive locks * @ author xiaojie * @ date 23:28 on 2021-12-30 * @ version 1.0 * / public class ReadAndWrite {static class ReadThred extends Thread {private ReentrantReadWriteLock lock; private String name; public ReadThred (String name, ReentrantReadWriteLock lock) {super (name) This.lock = lock;} @ Override public void run () {try {lock.readLock () .lock (); System.out.println (Thread.currentThread () .getName () + "this is a shared lock.") ;} catch (Exception e) {e.printStackTrace ();} finally {lock.readLock () .unlock (); System.out.println (Thread.currentThread () .getName () + "lock released successfully.") ;}} static class WriteThred extends Thread {private ReentrantReadWriteLock lock; private String name; public WriteThred (String name, ReentrantReadWriteLock lock) {super (name); this.lock = lock;} @ Override public void run () {try {lock.writeLock () .lock () Thread.sleep (3000); System.out.println (Thread.currentThread (). GetName () + "this is an exclusive lock.") ;} catch (Exception e) {e.printStackTrace ();} finally {lock.writeLock (). Unlock (); System.out.println (Thread.currentThread (). GetName () + "release lock.") ;}} public static void main (String [] args) {ReentrantReadWriteLock reentrantReadWriteLock = new ReentrantReadWriteLock (); ReadThred readThred1 = new ReadThred ("read-thread-1", reentrantReadWriteLock); ReadThred readThred2 = new ReadThred ("read-thread-1", reentrantReadWriteLock); WriteThred writeThred1 = new WriteThred ("write-thread-1", reentrantReadWriteLock); WriteThred writeThred2 = new WriteThred ("write-thread-2", reentrantReadWriteLock) ReadThred1.start (); readThred2.start (); writeThred1.start (); writeThred2.start ();}} 8, interruptible and uninterruptible locks

Interruptible lock A lock that can only be interrupted in the process of preemption, such as ReentrantLock.

Uninterruptible locks are uninterruptible locks such as the java built-in lock synchronized.

Summary:

Name

Advantages

Shortcoming

Working with scen

Bias lock

Locking and unlocking does not require CAS operations, there is no additional performance consumption, and there is only a nanosecond gap compared to executing asynchronous methods

If there is lock contention between threads, it will lead to additional consumption of lock revocation.

Suitable for scenarios where only one thread accesses fast synchronization

Lightweight lock

Competing threads do not block, improving response speed

If a thread becomes a thread that never gets lock contention, using spin will consume CPU performance

In pursuit of response time, fast synchronization and very fast execution

Weight lock

Thread contention is not suitable for spin and will not consume CPU

Thread blocking, slow response time, in multithreading, frequent acquisition and release of locks, will bring huge performance consumption

In pursuit of throughput, fast synchronization and long execution speed

Thank you for your reading, the above is the content of "what are the locks in JUC concurrent programming". After the study of this article, I believe you have a deeper understanding of what locks in JUC concurrent programming have, and the specific use needs to be verified in practice. Here is, the editor will push for you more related knowledge points of the article, welcome to follow!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.