Lock level from low to high:
No lock -> biased locking -> Lightweight lock -> Lock heavyweight
Lock sub-level reasons:
No previous optimization, sychronized heavyweight lock (pessimistic locking), using wait and notify, notifyAll to switch the thread state is very consuming system resources; thread suspend and wake-up interval is very short, this is a waste of resources and impact performance. So JVM to sychronized keyword optimized, no lock into the lock, tend to lock, lock lightweight, heavyweight lock status.
No Lock: no lock on the resources, all the threads can access and modify the same resources, but at the same time only one thread can modify success, other modifications fail thread will continue to retry until modified successfully.
Biased locking: Object code is always executed in the same thread, multiple threads of competition does not exist, the thread automatically get locked in the subsequent implementation, reduce the lock acquisition brings performance overhead. Biased locking, refers to bias the first locking thread that does not seek the release of biased locking only when another thread tries to compete biased locking will be released.
Biased locking revocation, requires no byte code is being executed, the first thread has suspended biased locking in some point in time, then the object is to determine whether the lock is locked. If the thread is not active, then the head object is set to non-locking state, and to withdraw biased locking;
If the thread is active, upgraded to status lightweight lock.
Lock Lightweight: Lightweight lock means that when the lock is biased locking time, be accessed by the second thread B, this time it will be upgraded to lightweight biased locking lock, thread B tries in the form of spin acquiring the lock, the thread will not be blocked, which improves performance.
Currently only one waiting thread, the thread will wait by the spin. But when more than a certain number of spins, lightweight lock will be upgraded to a heavyweight lock; When a thread already holds the lock, another thread in the spin, but this time there visiting third thread, light middleweight lock will be upgraded to heavyweight lock.
Heavyweight lock: that when one thread acquires the lock after all other threads waiting to acquire the lock will be in blocking state.
Heavyweight locks inside the object by the monitor (monitor) to achieve, monitor and nature of which is dependent on the underlying operating system Mutex Lock implementation, the operating system switching between threads need to switch from user mode to kernel mode, the switching cost is very high.
Lock status comparison:
|
|
Biased locking |
Lightweight lock |
Heavyweight lock |
| Applicable scene |
Only one thread to enter the synchronized block |
Although many threads, but there is no conflict: multiple threads to enter the synchronized block, but the thread into the lock stagger and thus did not compete |
Lock contention situation has occurred: multiple threads enter a synchronization block and lock contention |
| Nature |
Cancel sync operation |
Instead of exclusive operation of synchronous CAS |
Mutex synchronization |
| advantage |
(Required only when CAS first gets biased locking operation, but later than ThreadId) is not blocked, high efficiency |
Do not block |
CPU does not Depletion |
| Shortcoming |
Applicable scene too limited. If the competition is generated, there will be extra biased locking revocation consumption |
Depletion of CPU time not obtain lock |
Obstruction, context switching, heavyweight operation, the operating system consumes resources |
Part excerpt:
http://www.jetchen.cn/synchronized-status/
https://www.liangzl.com/get-article-detail-17940.html
Java interview questions summary, there is always a stuck you!
