principle:
The jdk method is that when a thread gets the lock first, we think that the lock is biased towards it. The actual method is to put the thread's in the object header of the object. (Upgrade from biased lock to lightweight as long as there is competition)
When a thread accesses a synchronization code block and tries to acquire a lock, first compare whether the current thread ID is consistent with the thread ID of the biased lock (whether the biased lock is 1).
If it is consistent, it means that the thread is still acquiring (reentrant), and there is no need to lock and unlock. If it is
inconsistent, other threads occupy the biased lock, because the biased lock cannot be released actively, then check whether the thread holding the biased lock is alive
or not: then directly reset to * **Unlocked status***, other threads can compete to set it as a biased lock
to survive, then wait for the thread that owns the lock to enter the safe zone and pause, the stack with the biased lock will be executed, and the lock record of the biased object will be traversed. The lock record in and the Mark Word of the object header, either re-bias to other threads, or restore to no lock or mark the object is not suitable as a bias lock, and finally wake up the suspended thread
The goal of biased locks: to reduce the performance loss of using lightweight locks when there is no competition and only one thread uses the lock
Biased locks vs lightweight locks
Lightweight lock requires at least one CAS for each application/release lock
Biased lock requires CAS only for initialization
Disadvantages: If there are obviously other threads competing for the lock, it will quickly expand into a lightweight lock (but the side effects are much less)
Acquisition of biased locks
When a thread accesses the synchronization block and acquires the lock, it will store the lock-biased thread ID in the lock record in the object header and stack frame, and then the thread does not need to spend CAS operations to lock and unlock when entering and exiting the synchronization block , and simply test whether the biased lock pointing to the current thread is 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 competition lock, if set, try to use CAS to point the biased lock of the object head to the current thread.
Cancellation 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 cancellation of the biased lock needs to wait for the global security point (at this point in time, no bytecode is being executed), it will first suspend the thread holding the biased lock, and then check whether the thread holding the biased lock is alive, if the thread is not active state, set the object header to a lock-free state. If the thread is still alive, the stack with a biased lock will be executed, and the lock record of the biased object, the lock record in the stack and the Mark Word of the object header will be traversed, or it will be biased to other The thread, either reverts to lock-free or marks the object as unsuitable for a biased lock, and finally wakes up the suspended thread.
Bias lock setting
Turn off biased locks: Biased locks are enabled by default in Java 6 and Java 7, but they are activated a few seconds after the application starts. If necessary, you can use the JVM parameter to turn off the delay -XX:BiasedLockingStartupDelay=0. If you are sure that all the locks in your application are usually in a competitive state, you can turn off the biased lock through the JVM parameter -XX:-UseBiasedLocking=false, then it will enter the lightweight lock state by default