Java Lock Optimization

First, the weight of class lock

In Java, synchronized is implemented through a monitor lock inside the object. But the nature of the monitor lock is implemented by the mutex lock which relies on the underlying operating system. and the operating system to implement the switch between the threads that need to transition from the user state to the nuclear mentality, the cost is very high, the transition between States need a relatively long time, which is why the low efficiency of synchronized reasons. Therefore, the lock that relies on the operating system mutex lock is what we call the "heavyweight lock." The core of the various optimizations made to synchronized in the JDK is to reduce the use of this heavyweight lock. After JDK1.6, "lightweight locks" and "biased locks" have been introduced to reduce the performance cost of obtaining locks and release locks, and to improve performance.

Second, lightweight lock

There are four types of locks: lock-free, biased, lightweight, and heavy-lock. As the lock competes, the lock can be upgraded from a biased lock to a lightweight lock, and then to a heavyweight lock (but the lock upgrade is one-way, that is, it can only be upgraded from low to high, and there is no downgrade of the lock). In JDK 1.6, the default is to turn on biased and lightweight locks, and we can also disable biased locks via-xx:-usebiasedlocking. The state of the lock is saved in the object's header file, as an example of a 32-bit JDK:

Lock status	-bit			4bit	1bit	2bit
	23bit		2bit		Whether the lock is biased	Lock Flag bit
Lightweight lock	Pointer to lock record in stack					00
Heavy-weight lock	Pointer to mutex (heavyweight lock)					10
GC Flag	Empty					11
Biased lock	Thread ID	Epoch		Age of Object generation	1	01
No lock	Hashcode of objects			Age of Object generation	0	01

"Lightweight" is relative to traditional locks implemented using operating system mutexes. However, the first thing to emphasize is that lightweight locks are not used in place of a heavyweight lock, and it is intended to reduce the performance cost of traditional heavy-lock use without multi-threaded competition. Before explaining the execution of a lightweight lock, it is important to understand that a lightweight lock adapts to a scenario where a thread alternately executes a synchronization block, and if there is a condition that accesses the same lock at the same time, it causes the lightweight lock to expand to a heavyweight lock.

1, the lock process of lightweight lock

(1) When the code enters the synchronization block, if the synchronization object lock state is no lock state (the lock flag bit is "01" state, whether the bias lock is "0"), the virtual machine will first establish in the current thread's stack frame a space named lock record, to store the lock object the current mark Word's copy, officially called displaced Mark Word. This is the thread stack as shown in state 2.1 of the object header.

(2) Mark Word in the Copy object header is copied to the lock record.

(3) After the copy succeeds, the virtual machine uses the CAS operation to attempt to update the object's mark Word to a pointer to the lock record and to point the owner pointer in the lock record to object Mark Word. If the update succeeds, perform step (3), otherwise perform step (4).

(4) If the update action succeeds, the thread has a lock on the object, and the object Mark Word's lock flag bit is set to "00", which means that the object is in a lightweight lock state, when the thread stack is as shown in state 2.2 of the object header.

(5) If this update fails, the virtual machine first checks to see if the object's mark word points to the current thread's stack frame, and if it means that the current thread already has the lock on the object, it can go straight to the synchronization block and proceed. Otherwise, multiple threads compete for a lock, the lightweight lock expands to a heavyweight lock, the status value of the lock flag changes to "ten", and Mark Word stores a pointer to a heavyweight lock (mutex), and the thread that waits for the lock goes into a blocking state. The current thread attempts to use a spin to acquire the lock, and the spin is the process of taking a loop to get the lock to keep the thread from blocking.

Figure 2.1 Lightweight lock CAs operation before stack with the state of an object

Figure 2.2 The state of the stack and object after a lightweight lock CAS operation

2. The process of unlocking the lightweight lock:  (1) The CAS operation attempts to replace the displaced mark Word object copied in the thread with the current Mark Word. 　　(2) If the replacement succeeds, the entire synchronization process is complete. (3) If the substitution fails, indicating that another thread has attempted to acquire the lock (when the lock is inflated), it is necessary to wake the suspended thread while releasing the lock. 3. Summary: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.

Third, biased lock

A bias lock will favor the first thread that gets it. Biased locking is introduced to minimize unnecessary lightweight lock execution paths in the absence of multi-thread contention, since the acquisition and release of lightweight locks relies on multiple CAs atomic instructions, The bias lock only needs to rely on the CAS Atom directive at the time of displacement threadid (because of the multi-threaded competition, the bias lock must be revoked, so the performance loss of the reverse lock operation must be less than the performance consumption of the saved CAs atomic instructions). As mentioned above, lightweight locks are designed to improve performance when a synchronization block is alternately executed on a thread, whereas a biased lock can further improve performance if only one of the threads executes the synchronization block.

1, biased lock acquisition process:

(1) Access Mark Word in favor of the identity of the lock is set to 1, whether the lock flag bit is 01--is considered to be biased.

(2) If it is a biased state, the test thread ID points to the current thread, if it is, enter step (5), otherwise enter step (3).

(3) If the thread ID does not point to the current thread, a competition lock is operated through CAs. If the competition succeeds, the mark Word line ID is set to the current thread ID, and then (5) is executed (4) if the competition fails.

(4) If the CAS acquires a biased lock failure, it indicates a competition. When the global security Point (SafePoint) is reached, the thread that obtains the bias lock is suspended, the bias lock is promoted to a lightweight lock, and then the thread that is blocked at the security point continues to execute the synchronization code.

(5) Execute the synchronization code.

2, favor the release of the Lock:

　　The revocation of a bias lock is mentioned in the above step . biased lock the thread that holds the biased lock releases the lock only when it encounters another thread trying to compete for a biased lock, and the thread does not voluntarily release the biased lock. A bias lock revocation, which waits for a global security point (at which no bytecode is executing), first pauses the thread that has a biased lock, determines whether the lock object is locked, reverts to an unlocked (flag bit "01"), or a lightweight lock (the flag bit is "00").

3. Conversion between heavyweight lock, lightweight lock and bias lock

Figure 2.3 Conversion diagram of the three

The figure is mainly a summary of the above content, if you have a better understanding of the above content, the diagram should be easy to read.

Java Lock Optimization