write in front
Let's still describe what these three locks are: Here is directly pasted from "In-depth Understanding of Java Virtual Machine".
Bias lock
The authors of Hotspot have found through previous research that in most cases, locks not only do not have multi-thread competition, but are always acquired by the same thread multiple times. In order to make the cost of thread acquisition of locks lower, biased locks are introduced. When a thread accesses a synchronized block and acquires a lock, it will store the lock-biased thread ID in the lock record in the object header and stack frame. Later, the thread does not need to spend CAS operations to lock and unlock when entering and exiting the synchronized block. , and simply test whether there is a biased lock pointing to the current thread stored in the Mark Word of the object header. If the test is successful, it means that the thread has acquired the lock. If the test fails, you need to test the biased lock in the Mark Word again. Whether the flag is set to 1 (indicating that it is currently a biased lock), if not set, use CAS to compete for the lock, if it is set, try to use CAS to point the biased lock of the object header to the current thread.
Revocation of biased locks: Biased locks use a mechanism that waits until competition occurs before releasing the lock, so when other threads try to compete for the biased lock, the thread holding the biased lock will release the lock. The revocation of the biased lock requires waiting for a global safepoint (at which point no bytecode is executing), it will first suspend the thread holding the biased lock, then check if the thread holding the biased lock is alive, if the thread is not active If the thread is still alive, the stack with the biased lock will be executed, traversing the lock record of the biased object, the lock record in the stack and the Mark Word of the object header or re-biased to other threads , either revert to lock-free or mark the object as unsuitable as a biased lock, and finally wake up the suspended thread.
Lightweight lock
Lightweight lock locking: Before the thread executes the synchronization block, the JVM will first create a space for storing the lock record in the stack frame of the current thread, and copy the Mark Word in the object header to the lock record, which is officially called the lock record. Displaced Mark Word. The thread then attempts to use CAS to replace the Mark Word in the object header with a pointer to the lock record. If it succeeds, the current thread acquires the lock. If it fails, it means that other threads compete for the lock, and the current thread tries to use spin to acquire the lock. If there are more than two threads contending for the same lock, the lightweight lock is no longer valid. To expand into a heavyweight lock, the status value of the lock flag becomes "10", and the Mark Word stores a pointer to the heavyweight lock. (mutex) pointer.
Lightweight lock unlocking: When lightweight unlocking, an atomic CAS operation is used to replace the Displaced Mark Word back to the object header. If successful, no competition occurs. If it fails, it means that the current lock is competing, and the lock will swell into a heavyweight lock.
Personal understanding:
Bias locks, lightweight locks are optimistic locks, heavyweight locks are pessimistic locks.
When an object is first instantiated, there are no threads to access it. It is biasable, meaning that it now thinks that only one thread can access it, so when the first thread comes to access it, it will favor this thread, at which point the object holds the biased lock. Biased to the first thread, this thread uses the CAS operation when modifying the object header to become a biased lock, and changes the ThreadID in the object header to its own ID. When accessing the object again, it only needs to compare the ID, no need to use it again. CAS is operating. Once a second thread accesses the object, because the biased lock will not be actively released, the second thread can see the biased state of the object, which indicates that there is already a competition on this object, check the object lock that was originally held If the thread is still alive, if it hangs, you can change the object to a lock-free state, and then re-bias the new thread. If the original thread is still alive, the operation stack of that thread is executed immediately to check the usage of the object. If the biased lock still needs to be held, the biased lock is upgraded to a lightweight lock (the biased lock is upgraded to a lightweight lock at this time). If it is no longer in use, the object can be reverted to a lock-free state and then redirected.
Lightweight locks believe that competition exists, but the degree of competition is very light. Generally, two threads will stagger the operation of the same lock, or wait a little (spin), and the other thread will release the lock. But when the spin exceeds a certain number of times, or one thread is holding the lock, one is spinning, and there is a third visit, the lightweight lock expands into a heavyweight lock, and the heavyweight lock makes all threads other than the thread that owns the lock. The threads are blocked, preventing the CPU from idling.