Java Lightweight lock principle detailed (lightweight Locking)

As you know, the multithreading security of Java is implemented based on the lock mechanism, and the performance of lock is often unsatisfactory.
The reason is that Monitorenter and Monitorexit, the two bytecode primitives that control multithreading synchronization, are implemented by the JVM relying on operating system mutexes (mutexes).
A mutex is a resource-intensive operation that causes a thread to hang and, in a short time, needs to be re-dispatched back to the original thread.

In order to optimize the lock mechanism of Java, the concept of lightweight locking was introduced from JAVA6.

The lightweight lock (lightweight Locking) is intended to reduce the chance of multiple threads entering the mutex, and not to replace the mutex.
It uses the CPU primitive Compare-and-swap (CAS, assembly instruction Cmpxchg) to try to remediate before entering the mutex.

This article details how the JVM uses CAs to implement lightweight locks.

Explanation of principle

Defined in the Java object model, the object header is a 2-word (1 word = 4 byte) length storage area.
The first word-length area is used to mark synchronization, GC, and hash code, which the authorities call mark Word. The second word length area is the class that points to the object.

In 2 word, Mark Word is the key to a lightweight lock implementation. Its structure is shown in the following table

As you can see from the table, the line that state is lightweight locked is a lightweight lock tag. The bitfieds name is a pointer to the lock record, where the lock record is actually a piece of space allocated on the thread stack .
Before CAs, copy mark Word on object (why copy, see below).
The third item is the heavyweight lock mark. The later state word is very interesting, inflated, the expansion, in this meaning is actually the lock has been upgraded to Os-level.
Within the scope of this article, we focus on the second and third items only.

In order to intuitively understand the connection between Lock,unlock and Mark Word, I drew a flowchart:

In the illustration, the Copy object Mark Word is mentioned, and because it is divorced from the original Mark Word, it is officially prefixed with the displaced prefix, that is, displaced mark Word(the permutation tag word).
This displaced mark Word is the key to the entire lightweight lock implementation, and compare in CAS needs to be used as a condition.

Why copy Mark Word?
It's really simple, because you don't want to be in sync with lock and unlock.

After the object mark Word is copied, the JVM does a step-through exchange of pointers , as described in the first orange rectangular box in the process.
The lightweight lock pointer in object mark Word points to the stack pointer where the lock record is located, so that other threads know that the object monitor is already occupied.
The owner pointer in the lock record points to object Mark Word's purpose in order to identify which object is locked during the next run.

Visually describes the operation of the Exchange pointer.

In the final step unlock, we found that the JVM also used CAs to verify that object mark Word was accessed by other threads in between holding the lock to the release lock.
If another thread attempts to acquire a lock during the time it holds the lock, it may be suspended itself, and Mark Word's heavyweight lock pointer will be modified accordingly.
At this point, the suspended thread needs to be awakened after the unlock.

Reprint please specify the original link: Http://kenwublog.com/theory-of-lightweight-locking-upon-cas

Java Lightweight lock principle detailed (lightweight Locking)