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

This article shows you what the principle of Synchronized in Java is. It is concise and easy to understand. It will definitely brighten your eyes. I hope you can get something through the detailed introduction of this article.

The original problem

Synchronized is implemented based on the Mutex Lock of the underlying operating system. Each operation of acquiring and releasing locks will bring about the switch between user mode and kernel state, thus increasing the system performance overhead.

Therefore, in the case of fierce lock competition, the performance of Synchronized synchronous lock is very poor, and it is often called heavyweight lock.

In the JDK1.5 version, the Lock interface is added to the concurrent package to implement the locking function, which provides a synchronization function similar to the Synchronized keyword, but needs to be displayed to acquire the lock and release the lock.

In the case of a single thread repeatedly applying for a lock, the performance of the JDK1.5 version of Lock is much better than that of Synchronized locks, that is, Synchronized does not have the function of reentrant locks at that time.

So how did Synchronized come true at that time? And why not have the function of reentrant?

Synchronized principle

Synchronization in JVM is based on entry and exit Monitor objects. Each object instance has a Monitor,Monitor that can be created and destroyed with the object.

When multiple threads access a piece of synchronous code at the same time, multiple threads are first stored in the EntryList collection (also known as a blocking queue), and threads in the BLOCKED state are added to the list.

Next, when the thread obtains the Monitor of the object, the Monitor relies on the Mutex Lock of the underlying operating system to achieve mutual exclusion. If the thread successfully applies for the Mutex, it holds the Mutex, and other threads will not be able to get the Mutex.

If a thread calls the wait () method, the currently held Mutex is released, and the thread enters the WaitSet collection (also known as the wait queue), waiting for the next time it wakes up. At this point, the thread will be in the WAITING or TIMEDWAITING state

If the current thread finishes executing the method successfully, the Mutex will also be released.

Generally speaking, synchronous lock in this implementation, because Monitor depends on the underlying operating system implementation, there is a switch between user mode and kernel state (which can be understood as context switching), so it increases the performance overhead.

Lock upgrade

In order to improve performance, JDK1.6 introduces the concepts of biased lock, lightweight lock and heavyweight lock to reduce the context switch caused by lock competition, and it is the new Java object header that implements the lock upgrade function.

By lock upgrade, I mean

> the Synchronized synchronization lock is biased at first, but as the thread competition becomes more and more fierce, the bias lock is upgraded to lightweight lock, and finally to heavy lock.

Bias lock

The biased lock is mainly used to optimize the competition in which the same thread applies for the same lock many times, that is, the current Synchronized lock actually has the function of reentrant lock.

Why is there a bias lock? Because in our application, it is possible to compete with the same thread for lock resources most of the time (for example, a single thread operates a thread-safe container), if the thread acquires and releases the lock every time, then constantly switch between kernel mode and user mode.

So with a bias lock, when a thread accesses the synchronization code or method again, the thread only needs to go to the object header to determine whether the current thread holds the bias lock or not.

Once other threads compete for lock resources, the biased lock is revoked. The revocation of the bias lock needs to wait for the global safe point (JVM's stop the world), suspend the thread holding the lock, and check to see if the thread is still executing the method, and if so, upgrade the lock, otherwise it will be preempted by other threads.

Lightweight lock

When another thread competes to acquire the lock, because the lock is already biased, when it is found that the thread ID in the object header is not its own thread ID, it will perform the CAS operation to acquire the lock. If it is successful, it will directly replace the thread ID in the object header with its own ID, and the lock will remain biased lock state; if the lock fails, it means that there is some competition in the current lock, and the preferred lock will be upgraded to a lightweight lock.

Lightweight locks are suitable for scenarios where threads execute synchronous blocks alternately, and most locks do not compete for a long time during the whole synchronization cycle.

Lightweight locks also support spin, so when other threads scramble again, if the CAS fails, they will no longer enter the blocking state, but will continue to spin.

Spin is better because, as mentioned earlier, the default thread does not hold the lock for too long, and it may be more expensive if the thread is suspended and blocked.

If the preemptive lock still fails after the spin lock is retried, the synchronization lock is upgraded to a heavy lock.

Weight lock

In this state, threads that do not grab the lock enter the Monitor, which is then blocked in the WaitSet collection, which becomes the Synchronized lock before optimization.

JVM parameter optimization

Stop the world occurs when a bias lock is upgraded to a lightweight lock. If the system is often multithreaded, it may be a better choice to prohibit the bias lock, which can be optimized by the following JVM parameters:

/ / turn off bias lock (on by default)-XX:-UseBiasedLocking// setting heavyweight lock-XX:+UseHeavyMonitors

Lightweight lock has the function of spin lock, so if the thread holds the lock for a long time, then the competing thread will often be in the spin state, occupy the system CPU, and increase the system overhead, so it is better to turn off the spin lock optimization at this time:

-XX:-UseSpinning the above is what is the principle of Synchronized in Java. Have you learned any knowledge or skills? If you want to learn more skills or enrich your knowledge reserve, you are welcome to follow the industry information channel.

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.