JVM internal details 2: biased locking)

In the previous article "JVM internal details: Synchronized keywords and implementation details", we have mentioned the concept of biased locking, before understanding what is a biased lock, you must first understand what is a lightweight lock ). The introduction of biased locks aims to minimize unnecessary lightweight lock execution paths without multi-thread competition, because the acquisition and release of lightweight locks depend on cas atomic commands for multiple times, the biased lock only needs to rely on the CAS atomic command once when the threadid is replaced (because the biased lock must be revoked once the multi-thread competition occurs, therefore, the performance loss of the lock-biased Undo operation must be less than the performance consumption of the saved CAS atomic commands ). See the details below:

1. Mark word layout in the object header

 

In the lightweight locks discussed in the previous article, the implementation of heavyweight locks in the paper I reference is not expressed through the status bit, but directly links an underlying operating system in the monitor record of the lightweight locks. mutex semaphores to implement heavyweight lock operations (does not affect our understanding of the operation process of JVM internal locks ), heavyweight locks are not involved in the processing of biased locks. Here we only need to care about the biasable and lightweight locked statuses. After jdk1.6, the optimization of biased lock is enabled by default. We can add-xx when starting JVM: -usebiasedlocking is used to disable biased locks (disabling biased locks in an environment with a large number of lock objects created and highly concurrent results in performance optimization ).

Ii. process of obtaining biased locks (assuming bias lock optimization is enabled ):

(1) When the object is in the biasable state, and threadid is 0, that is, the biasable & unbiased state (EPOCH and age are not discussed here)

(2) When a thread attempts to lock an object in the biasable & unbiased state, it places its threadid in the corresponding position of Mark word through a CAS, if the CAS operation is successful, go to step (3). Otherwise, go to step (4 ).

(3) When there is no lock competition in the table in this step, the object continues to be in the biasable state, but the threadid field is set to the ID of the owner biased towards the lock, then go to step (6 ).

(4) The current thread fails to execute CAs to obtain the biased lock (this step is the key to the biased lock), indicating that there is competition on the Lock Object and another thread obtains the biased lock ownership at this time. When a thread arrives at a global security point (safepoint), the thread that obtains the biased lock is suspended and an idle record is obtained from the private monitor record list of the biased lock owner, and set the object to lightweight lock status, And the lockrecord in Mark word points to the monitor record holding the biased lock thread, and the thread blocking at the security point is released, go to the execution path of the lightweight lock, and the thread that is removed from the biased lock continues to execute the synchronization code.

(5) When a thread tries to lock a thread in biasable & biased and threadid is not equal to its own ID, it must go to step (4) to cancel the biased lock due to lock competition.

(6) run the synchronization code block

Ii. Locking process:

(1) The process of locking is simple. You only need to test whether the biased lock mode on the object exists. If yes, no additional operations are required for unlocking.

 

Iii. References:

• eliminating synchronization-related atomic operations with biased locking and bulk rebiasing