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

This article mainly explains "what is the core principle of Java synchronized bias lock". Interested friends may wish to take a look. The method introduced in this paper is simple, fast and practical. Let's let the editor take you to learn "what is the core principle of Java synchronized bias lock"?

1. The core principle of bias lock

Lightweight locks still need to perform CAS operations each time they reenter when there is no competition (just their own thread). Biased locks have been introduced in Java 6 for further optimization: only the first time you use CAS to set the thread ID to the object's Mark Word header, and then finding that the thread ID is its own means there is no competition and no need to re-CAS. In the future, as long as there is no competition, the object belongs to the thread.

Public class Main {static final Object obj = new Object (); public static void main (String [] args) {Thread thread = new Thread (()-> {M1 ();}); thread.start ();} public static void M1 () {synchronized (obj) {/ / synchronous block A m2 () }} public static void m2 () {synchronized (obj) {/ / Sync Block B m3 ();}} public static void m3 () {synchronized (obj) {/ / bias status / / Sync Block C}

The core principle of biased lock is: if there is no thread contending for a thread to acquire the lock, then the lock enters the biased state, and the structure of the Mark Word becomes biased lock structure, the lock log bit (lock) of the lock object is changed to 01, the bias flag bit (biased_lock) is changed to 1, and then the thread's ID is recorded in the lock object's Mark Word (completed using the CAS operation). In the future, when the thread acquires the lock, it can judge the thread ID and flag bits, and then it can directly enter the synchronization block, and even the CAS operation is not needed, which saves a lot of lock application operations and improves the performance of the program.

The main function of the biased lock is to eliminate the synchronization primitive without competition and further improve the program performance. therefore, the biased lock has a good optimization effect when there is no lock competition. However, once a second thread needs to compete for a lock, the biased mode immediately ends and enters a lightweight lock state.

If there is no competition for synchronization blocks in most cases, performance can be improved through bias. That is, when there is no competition, the thread that previously acquired the lock will determine whether the lock-biased thread ID points to itself when it acquires the lock again. If so, the thread will not need to acquire the lock again and can enter the synchronization block directly. If it does not point to the current thread, the current thread will use the CAS operation to set the thread ID in Mark Word to the current thread ID. If the CAS operation is successful, then the bias lock will be acquired successfully, and the synchronous code block will be executed. If the CAS operation fails, it indicates that there is competition. The lock grabbing thread is suspended, revoking the bias lock occupying the lock thread, and then inflating the bias lock into a lightweight lock.

The locking process of biased lock is as follows: the new thread only needs to judge whether the thread ID in the Mark Word of the built-in lock object is its own ID, and if it is, use the lock directly instead of using the CAS exchange; if not, for example, when the thread ID of the built-in lock is empty for the first time, then use the CAS exchange, and the new thread swaps its own thread ID into the Mark Word of the built-in lock. If the exchange is successful, the lock is successfully added.

For each round of preemption, JVM compares the built-in lock bias thread ID with the current thread ID. If it matches, the current thread has acquired the bias lock, and the current thread can quickly enter the critical area. Therefore, the efficiency of biased locking is very high. In short, the bias lock is for a thread, and after the thread acquires the lock, there will be no more operations such as unlocking, which can save a lot of overhead.

The disadvantage of the lock bias: if the lock object is often contended by multiple threads, the lock bias is redundant, and the process of undoing will incur some performance overhead.

two。 Revocation of bias lock

If there are multiple threads competing for a biased lock, this object lock is already biased, and other threads find that the biased lock is not biased towards them, indicating that there is competition and try to undo the biased lock (possibly introducing a security point). And then inflate to a lightweight lock.

The overhead of biased lock revocation is quite high, and the process is roughly as follows:

(1) stop the thread that owns the lock at a safe point.

(2) iterate through the stack frame of the thread to check whether there is a lock record. If there is a lock record, you need to empty the lock record, make it unlocked, repair the Mark Word that the lock record points to, and clear its thread ID.

(3) upgrade the current lock to a lightweight lock.

(4) Wake up the current thread.

Therefore, if there is two or more thread competition in some critical areas, then biased locking can degrade performance. In this case, you can turn off the default feature of biased locks when you start JVM.

Conditions for revoking biased locks:

(1) multiple threads compete for biased locks.

(2) after calling the hashcode () method or the System.identityHashCode () method to calculate the HashCode of the object, the hash code is placed in the Mark Word, the built-in lock becomes unlocked, and the bias lock will be revoked.

3. Biased lock expansion

If the biased lock is occupied, once a second thread scrambles for the object, because the biased lock will not be released actively, the second thread can see the built-in lock bias state, indicating that there is already competition on this object lock. JVM checks whether the possession thread that used to hold the object lock is still alive, and if it dies, it can make the object unlocked, and then re-bias it to a lock-grabbing thread.

If JVM detects that the original thread is still alive, it further checks whether the call stack that occupies the thread holds the bias lock through the lock record. If there is a lock record, it indicates that the original thread is still using biased locks, lock contention occurs, the original biased locks are revoked, and the biased locks are INFLATING to lightweight locks.

4. Benefits of biased locking

Experience has shown that, in most cases, threads entering a synchronous block of code are the same thread. This is why JDK introduces biased locks. So, in general, the benefits of using biased locks still outweigh the costs of biased lock revocation and expansion.

At this point, I believe you have a deeper understanding of "what is the core principle of Java synchronized bias lock". You might as well do it in practice. Here is the website, more related content can enter the relevant channels to inquire, follow us, continue to learn!

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.