The bias lock, lightweight locks are optimistic locking, pessimistic locking lock heavyweight.
First, simply under the first biased lock, lock lightweight, heavyweight lock their three scenarios:
- Biased locking: only one thread to enter the critical section;
- Lightweight lock: multiple threads alternately enter the critical section ;
- Heavyweight lock: multiple threads simultaneously enter the critical region.
Also clear is biased locking, lightweight JVM locks are introduced to optimize the lock means, the aim is to reduce the overhead of thread synchronization. For example, synchronized code blocks:
synchronized (lockObject) { // do something }There is a critical area of the synchronization code block, it assumed that the current presence of Thread # 1 and Thread # 2 both user threads, to discuss three cases:
- Case 1: Only Thread # 1 will enter the critical section;
- Case 2: Thread # 1 and Thread # 2 alternately enter the critical section;
- Case three: Thread # 1 Thread # 2 and at the same time to enter the critical section.
sychronized lock optimization Explanation 1:
First, the above situation applies biased locking scene, this time when Thread # 1 enters the critical region, JVM will lockObject head Mark Word object lock flag is set to "01", with the CAS will also operate the Thread # 1 thread ID is recorded in the Mark Word, this time into biased mode. The so-called "bias", referring to the lock will be biased in favor of Thread # 1, followed if no other thread enters the critical zone, Thread # 1 and then out of the critical region do not need to perform any synchronization operations. In other words, you need to perform the operation if the CAS only Thread # 1 will enter the critical region, in fact, only Thread # 1 for the first time to enter the critical section, later there will be no access to the critical section synchronization overhead caused.
First, however, a more ideal situation, the more time Thread # 2 will attempt to enter the critical region. If Thread # 2 tries to enter Thread # 1 has exited critical region, that at this time lockObject in an unlocked state, then state bias locked occurred competition (corresponding to Case 2) at this time will tend to withdraw, Mark Word no longer storing bias thread ID, but the store hashCode and generational GC age, while the lock flag to "01" (for unlocked), then thread # 2 will get a lightweight lock lockObject. Because at this time Thread # 1 Thread # 2 and alternately enter the critical region, so biased locking unable to meet demand, the need to expand to a lightweight lock.
Besides lightweight lock when it will expand to heavyweight lock. If it has been a Thread # 1 Thread # 2 and alternately enter the critical section, then no problem, lightweight lock hold live. Once the competition in the lightweight lock occurs, the situation is "Thread # 1 Thread # 2 and at the same time to enter the critical area" appears, it could not hold the lightweight lock. (Root cause is a lightweight lock is not enough space to store additional state at this time if the expansion is a heavyweight lock, lock all waiting lightweight threads can only spin, you may lose a lot of CPU time)
sychronized lock optimization explanation 2:
The beginning of an object is instantiated when no threads to access it at the time. It is biased, meaning that it now believes there may be only one thread to access it, so when the first thread to access it, it will tend to this thread, this time, the object holds biased locking. Toward the first thread, the thread used to modify the object to be biased locking head when the CAS operation, and the object header ThreadID into its own ID, time after visiting the object again, only need to compare ID, you do not need to use CAS during the operation.
Once the second thread has access to this object because biased locking will not take the initiative to release, so biased state when the second thread can see an object, then show that competition already exists on this object, the original holders of the inspection object lock whether the thread is still alive, if hung up, it can not become an object lock status, and then again toward a new thread if the original thread is still alive, then immediately perform an operation that the thread stack, examine the use of the object, If you still need to hold biased locking is biased locking upgraded to lightweight lock (lock is biased upgraded this time as a lightweight lock). If there is used, it can return to the non-lock state of the object, and then re-biased.
Lightweight lock that there is competition, but the degree of competition is very light, usually two threads for the same lock operations will stagger, or wait a little (spin), another thread releases the lock. But when in addition to the thread owns the lock spin more than a certain number of times, or a thread holding a lock, a spin, while another third visit, lightweight lock inflation heavyweight lock, the lock heavyweight the threads are blocked, preventing the CPU idle.