Shulou(Shulou.com)05/31 Report--

This article mainly explains "how to realize the synchronized lock expansion mechanism in Java". 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 "how to realize the synchronized lock expansion mechanism in Java".

Synchronized

In JDK 1.5, synchronized needs to call the monitor lock (Monitor) to implement, and the monitor lock essentially depends on the Mutex Lock (mutex lock) of the underlying operating system. When the mutex lock is released and acquired, it needs to switch from the user state to the kernel state, which results in a high cost and a long execution time. This kind of lock which depends on the implementation of the operating system Mutex Lock is called "heavyweight lock".

What is the household state and kernel state?

User Mode: when a process is executing the user's own code, it is said to be in the user's running state. Kernel Mode: when a task (process) executes a system call and falls into kernel code, we call the process in the kernel running state, and the processor executes in the kernel code with the highest privilege level.

Why divide kernel mode and user mode?

Assuming that there is no distinction between kernel mode and user mode, programs can read and write hardware resources at will, such as reading and writing at will and allocating memory, so that if programmers accidentally write inappropriate content to the wrong place, it is likely to cause the system to crash.

With the distinction between user state and kernel state, the program will carry out a series of verification and verification when performing an operation, and then it can operate resources normally after confirming that there is no problem. In this way, you will not worry about accidentally destroying the system, that is, with the distinction between kernel state and user state, you can make the program run more safely, but at the same time, switching between the two forms will lead to certain performance overhead.

Lock expansion

In JDK 1.6, in order to solve the performance consumption caused by acquiring and releasing locks, the states of "biased lock" and "lightweight lock" are introduced, and there are a total of four states of synchronized:

No lock

Bias lock

Lightweight lock

Weight lock

The level of the lock is upgraded in the above order, and we call this upgrade process "lock expansion".

PS: so far, lock upgrades have been one-way, that is, they can only be upgraded from low to high (no lock-> biased lock-> lightweight lock-> heavyweight lock), and there will be no lock degradation.

Why can lock expansion optimize the performance of synchronized? When we understand the state of these locks, we will naturally have the answer. Let's take a look at it.

Bias lock

Through research and practice, the author of HotSpot found that in most cases, there is no multi-thread competition, and the lock is always acquired by the same thread many times. In order to make it cheaper for the thread to acquire the lock, the biased lock is introduced.

Biased lock (Biased Locking) means that it will be biased towards the first thread to access the lock. If the synchronous lock is accessed by only one thread and there is no multithreaded contention, the thread does not need to trigger synchronization, in which case it will add a biased lock to the thread.

Biased lock execution flow

When a thread accesses the synchronized code block and acquires the lock, it stores the lock biased thread ID in the Mark Word of the object header. When the thread enters and exits the synchronous block, it no longer locks and unlocks through the CAS operation, but detects whether a biased lock pointing to the current thread is stored in the Mark Word. If the thread ID in the Mark Word is the same as the accessed thread ID, you can directly enter the synchronization block for code execution. If the thread ID is different. Use CAS to attempt to acquire the lock, and if successful, enter the synchronization block to execute the code, otherwise the state of the lock will be upgraded to a lightweight lock.

Advantages of biased locks

Biased locks are designed to minimize unnecessary lock switching without multi-thread competition, because the acquisition and release of locks depend on multiple CAS atomic instructions, while biased locks only need to execute CAS atomic instructions once when replacing thread ID.

Mark Word extended knowledge: memory layout

In a HotSpot virtual machine, the layout in which objects are stored in memory can be divided into the following three areas:

Object head (Header)

Instance data (Instance Data)

Align fill (Padding)

The object header also contains:

Mark Word (tag field): our biased lock information is stored in this area.

Klass Pointer (Class object pointer)

The layout of the object in memory is as follows:

Biased locks are turned on by default in JDK 1.6and can be disabled by the "- XX:-UseBiasedLocking=false" command.

Lightweight lock

The purpose of introducing lightweight locks is to reduce the performance consumption caused by the traditional heavyweight locks using the operating system Mutex Lock (mutex locks) without multi-thread competition. If each lock acquisition and release operation using Mutex Lock brings about a switch between user mode and kernel state, the performance overhead of the system is very high.

When the bias lock is turned off or multiple threads compete for the bias lock, the bias lock will be upgraded to a lightweight lock. The acquisition and release of the lightweight lock is done through CAS, in which lock acquisition may be done through a certain number of spins.

Matters needing attention

It needs to be emphasized that lightweight locks are not used to replace heavy locks, but are intended to reduce the performance consumption caused by the use of traditional heavyweight locks without multithreaded competition. Lightweight locks adapt to scenarios where threads execute synchronous blocks alternately, which will cause lightweight locks to expand to heavyweight locks if multiple threads access them at the same time.

Weight lock

Synchronized relies on the monitor Monitor to achieve method synchronization or code block synchronization, code block synchronization is achieved by using monitorenter and monitorexit instructions, monitorenter instruction is inserted into the beginning of the synchronous code block after compilation, and monitorexit is inserted into the end of the method and exception, any object has a Monitor associated with it, when and a Monitor is held, it will be locked.

Such as the following lock code:

Public class SynchronizedToMonitorExample {public static void main (String [] args) {int count = 0; synchronized (SynchronizedToMonitorExample.class) {for (int I = 0; I < 10; iTunes +) {count++;}} System.out.println (count);}}

When we compile the above code into bytecode, it looks like this:

From the above results, we can see that there are multiple instructions of monitorenter and monitorexit in the execution of the main method, so it can be seen that the synchronized relies on the Monitor monitor lock, and the monitor lock depends on the Mutex Lock of the operating system. Each time the mutex lock is acquired and released, it will bring about the switch between user mode and kernel state, which increases the performance overhead of the system.

Thank you for your reading, the above is the content of "how to achieve the synchronized lock expansion mechanism in Java". After the study of this article, I believe you have a deeper understanding of how to achieve this problem of the synchronized lock expansion mechanism in Java, 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.