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

Lock status and upgrade methods, I believe that many inexperienced people do not know what to do, so this paper summarizes the causes of the problem and solutions, through this article I hope you can solve this problem.

I. Preface

There are a total of four lock states, from low to high: no lock, bias lock, lightweight lock, heavy lock. What do these four lock states represent, and why is there lock upgrade? In fact, before JDK 1.6, synchronized was a heavy lock and relatively inefficient lock, but after JDK 1.6, Jvm optimized (synchronized) to improve the efficiency of lock acquisition and release, introducing bias lock and lightweight lock. From then on, there are four lock states (no lock, bias lock, lightweight lock, heavyweight lock), and the four states will gradually escalate with the competition. And it is an irreversible process, that is, it cannot be degraded, that is, locks can only be upgraded (from low-level to high-level), and locks can not be degraded (high-level to low-level), which means that biased locks cannot be degraded to biased locks after upgrading to lightweight locks. This lock upgrade strategy can not be degraded in order to improve the efficiency of acquiring and releasing locks.

Second, four states of the lock

In synchronized, the original implementation is "blocking or waking up a CPU thread requires the operating system to switch Java state, which takes processor time. If the content in the synchronization code block is too simple, the switching time may be longer than the user code execution time." this is the original way of synchronized synchronization, which is also criticized by developers at the beginning. This is also the reason for the inefficiency of synchronized before JDK6. In order to reduce the performance consumption caused by acquiring and releasing locks, "biased locks" and "lightweight locks" are introduced in JDK6.

So at present, there are four kinds of lock states, from low to high: no lock, bias lock, lightweight lock, heavy lock, lock state can only be upgraded, can not be degraded.

As shown in the figure:

Third, the ideas and characteristics of the lock state.

IV. Lock comparison

5. Synchronized lock

The locks used by synchronized are stored in the Java object header, so what is the object header?

5.1 Java object header

Let's take the Hotspot virtual machine as an example. The Hopspot object header mainly includes two parts of data: MarkWord (tag field) and KlassPointer (type pointer).

Mark Word: the default storage object's HashCode, generation age and lock mark bit information. This information is independent of the definition of the object itself, so Mark Word is designed as a non-fixed data structure to store as much data as possible in a very small amount of space. It reuses its own storage space according to the state of the object, that is, the data stored in the Mark Word will change with the change of the lock log bit during operation.

Klass Point: an object's pointer to its class metadata through which the virtual machine determines which class the object is an instance of.

As we know above, the locks used by synchronized are stored in the header of the Java object, so where exactly does the object header exist? The answer is: there is a MarkWord in the object header of the lock object, so what exactly does MarkWord look like in the object header, and what exactly does it store?

In a 64-bit virtual machine:

In a 32-bit virtual machine:

Let's take a 32-bit virtual machine as an example to see how the bytes of its Mark Word are allocated.

No lock: the object head opens up a space for 25bit to store the hashcode of the object, the 4bit is used to store the age of the object, the 1bit is used to store the identification bit of whether the lock is biased toward the lock, and the 2bit is used to store the lock identification bit of 01.

Biased lock: divide the biased lock more carefully, or open up the space for 25bit, where 23bit is used to store threads ID,2bit is used to store the age of Epoch,4bit storage objects, whether 1bit storage is biased towards lock identification, 0 indicates no lock, 1 indicates biased lock, and the identification bit of the lock is still 01

Lightweight lock: open up the space of 30bit directly in the lightweight lock to store the pointer to the lock record in the stack, and the flag bit of 2bit store the lock, whose flag bit is 00

Heavyweight locks: in heavyweight locks, like lightweight locks, 30bit space is used to store pointers to heavyweight locks, and 2bit stores the lock's identification bit, which is 11.

GC tag: open up 30bit memory space but do not occupy, 2bit space storage lock flag bit is 11.

The lock flag bit of both unlocked and biased locks is 01, but the previous 1bit distinguishes whether this is a lock-free state or a partial lock state.

With regard to the allocation of memory, we can see the markOop.hpp in openJDK in git:

Public: / / Constants enum {age_bits = 4, lock_bits = 2, biased_lock_bits = 1, max_hash_bits = BitsPerWord-age_bits-lock_bits-biased_lock_bits, hash_bits = max_hash_bits > 31? 31: max_hash_bits Cms_bits = LP64_ONLY (1) NOT_LP64 (0), epoch_bits = 2}

Age_bits: this is what we call the logo of generational recycling, which takes up 4 bytes

Lock_bits: is the flag bit of the lock and occupies 2 bytes

Biasedlockbits: indicates whether the lock is biased and occupies 1 byte

Maxhashbits: the number of bytes consumed by hashcode for unlocked calculation. If it is a 32-bit virtual machine, it is 32-4-2-1 = 25 byte. If it is a 64-bit virtual machine, 64-4-2-1 = 57 byte, but there will be 25 bytes unused, so the 64-bit hashcode takes up 31 byte.

Hash_bits: for 64-bit virtual machines, 31 is taken if the maximum number of bytes is greater than 31, otherwise the real number of bytes is taken.

Cms_bits: not 64-bit virtual machines occupy 0 byte, but 64-bit virtual machines occupy 1byte

Epoch_bits: the size of the bytes occupied by epoch, 2 bytes.

5.2 Monitor

Monitor can be understood as a synchronization tool or a synchronization mechanism, which is usually described as an object. Every Java object has an invisible lock, called an internal lock or Monitor lock.

Monitor is a thread-private data structure, and each thread has a list of available monitor record, as well as a global available list. Each locked object is associated with a monitor, and there is an Owner field in the monitor that holds the unique identity of the thread that owns the lock, indicating that the lock is occupied by that thread.

Synchronized is implemented through a monitor inside the object, which in essence depends on the Mutex Lock (mutex) of the underlying operating system. The operating system needs to switch from user mode to kernel state to switch between threads, which is very expensive, and the transition between states takes a relatively long time, which is why the efficiency of Synchronized is low. Therefore, this kind of lock which depends on the implementation of the operating system Mutex Lock is called a heavyweight lock.

With the competition of locks, locks can be upgraded from biased locks to lightweight locks, and then upgraded heavyweight locks (but lock upgrades are one-way, that is, they can only be upgraded from low to high, and there will be no lock degradation). Bias locks and lightweight locks are turned on by default in JDK 1.6. we can also disable bias locks through-XX:-UseBiasedLocking=false.

VI. Classification of locks 6.2 No locks

No lock means that the resource is not locked and all threads can access and modify the same resource, but only one thread can modify it successfully.

The characteristic of no lock is that the modification operation will be carried out in the loop, and the thread will constantly try to modify the shared resource. If there is no conflict, the modification succeeds and exits, otherwise the loop attempt will continue. If multiple threads modify the same value, one thread must be able to modify successfully, while other threads that fail to modify will try again and again until the modification is successful.

6.3 bias lock

When the synchronized code block is first executed, the lock object becomes biased (the lock flag bit in the object's header is modified by CAS), which literally means "in favor of the first thread to acquire it." After the synchronous code block is executed, the thread does not actively release the bias lock. When the synchronized code block is reached for the second time, the thread determines whether the thread holding the lock is itself (the thread holding the lock ID is also in the object header), and if so, it executes normally. Since the lock has not been released before, there is no need to re-lock here. If there is only one thread that uses the lock from beginning to end, it is clear that there is little extra overhead in favor of the lock, and the performance is extremely high.

Biased lock means that when a piece of synchronization code has been accessed by the same thread, that is, when there is no competition among multiple threads, then the thread will automatically acquire the lock on subsequent access, thus reducing the consumption caused by acquiring the lock, that is, improving performance.

When a thread accesses a synchronized block of code and acquires a lock, the thread ID for which the lock is biased is stored in Mark Word. Instead of locking and unlocking by CAS when a thread enters and exits a synchronized block, it detects whether a bias lock pointing to the current thread is stored in the Mark Word. The acquisition and release of lightweight locks depend on multiple CAS atomic instructions, while biased locks only need to rely on CAS atomic instructions once when replacing ThreadID.

Biased lock the thread holding the biased lock releases the lock only when another thread tries to compete for the biased lock, and the thread does not actively release the biased lock.

With regard to the revocation of the biased lock, we need to wait for the global security point, that is, when no bytecode is executing at a certain point in time, it will first pause the thread that owns the biased lock and then determine whether the lock object is locked or not. If the thread is not active, the object header is set to an unlocked state, and the biased lock is reversed to a state where there is no lock (flag bit 01) or lightweight lock (flag bit 00).

6.4 lightweight lock (spin lock)

Lightweight lock means that when the lock is biased towards the lock, it is accessed by another thread, and the preferred lock will be upgraded to a lightweight lock, and other threads will try to acquire the lock in the form of spin (see the end of the article for an introduction to spin). The thread will not block, thus improving performance.

There are two main ways to acquire lightweight locks: when ① turns off the bias lock function, and ② upgrades the bias lock to lightweight lock due to multiple threads competing for the bias lock.

Once a second thread joins the lock competition, the bias lock is upgraded to a lightweight lock (spin lock). Let's be clear here what lock contention is: if multiple threads take turns to acquire a lock, but each time the lock is acquired smoothly, there is no blocking, then there is no lock contention. Lock contention occurs only when a thread tries to acquire a lock and finds that the lock is occupied and can only wait for it to be released.

If the lock competition continues in the lightweight lock state, the thread that does not grab the lock will spin, that is, constantly loop to determine whether the lock can be successfully acquired. The operation of acquiring the lock is to modify the lock flag bit in the object header through CAS. First compare whether the current lock flag bit is "release", if so, set it to "lock", compare and set it to be atomic. This is considered to have grabbed the lock, and then the thread changes the owner information of the current lock to itself.

Long-time spin operations are very resource-consuming. While one thread holds a lock, other threads can only consume CPU in place and cannot perform any effective tasks. This phenomenon is called busy-waiting. If multiple threads use a lock, but there is no lock contention, or if there is a slight lock contention, then synchronized uses lightweight locks, allowing for short periods of busy, and so on. This is a compromise, a short period of busy, etc., in exchange for the overhead of switching threads between user mode and kernel state.

6.4 heavyweight lock

The heavyweight lock obviously has a limit to this busy wait (there is a counter that records the number of spins, which allows 10 cycles by default, which can be changed by virtual machine parameters). If the lock competition is serious, a thread that reaches the maximum number of spins will upgrade the lightweight lock to a heavyweight lock (CAS still modifies the lock flag bit, but does not modify the thread ID that holds the lock). When a subsequent thread tries to acquire a lock and finds that the occupied lock is a heavyweight lock, it hangs itself (rather than busy, etc.) and waits for it to be woken up in the future.

A heavyweight lock means that when a thread acquires a lock, all other threads waiting to acquire the lock are in a blocking state.

In short, all control is given to the operating system, which is responsible for scheduling between threads and changing the state of threads. In this way, the running state of the thread will be switched frequently, and the thread will be suspended and awakened, thus consuming a lot of system money.

After reading the above, have you mastered the status of the lock and how to upgrade it? If you want to learn more skills or want to know more about it, you are welcome to follow the industry information channel, thank you for reading!

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.