This is the 27th day of my participation in the Gwen Challenge.More article challenges
preface
Prior to JDK 1.6, synchronized was a heavyweight lock and a relatively inefficient lock. However, after JDK 1.6, THE Jvm optimized synchronized to improve lock acquisition and release efficiency by introducing biased locking and lightweight locking. Since then the state of the lock has four (not locked, biased locking, lightweight and heavyweight lock), and four state will as competition gradually upgrade, and it is irreversible process, which cannot be downgraded, that is to say, only lock escalation (from low level to high level), can’t lock down (high level to low level), This means biased locks cannot be downgraded to biased locks after being upgraded to lightweight locks. The purpose of this policy is to improve the efficiency of acquiring and releasing locks.
| The lock | advantages | disadvantages | Usage scenarios |
|---|---|---|---|
| Biased locking | Locking and unlocking require no additional cost, with a nanosecond difference compared to implementing asynchronous methods | If there is lock contention between threads, there is additional lock cancellation cost | This applies to scenarios where only one thread accesses a synchronized block |
| Lightweight lock | Competing threads do not block, improving the response time of the program | Using spin consumes CPU if you never get a competing thread | Pursuit of response speed, synchronous block execution speed is very fast |
| Heavyweight lock | Thread contention does not use spin and does not consume CPU | Threads are blocked and response time is slow | In pursuit of throughput, synchronous block execution is slow |
The classification of the lock
- unlocked
No lock means that no resource is locked. All threads can access and modify the same resource, but only one thread can modify the resource successfully. The feature is that the modification is performed within a loop, with threads constantly trying to modify the shared resource. If there are no conflicts, the modification succeeds and exits, otherwise the loop continues. If multiple threads modify the same value, one thread will succeed, and the others will retry until the modification succeeds.
- Biased locking
When a synchronized block is first implemented, a lock object becomes a bias lock (CAS modifies the lock flag bit in the object’s head), which literally means a lock “biased in favor of the first thread to acquire it.” The thread does not actively release bias locks after executing synchronized blocks of code. When a block of synchronized code is reached for the second time, the thread will determine whether the thread holding the lock is its own (the thread holding the lock ID is also in the object head), and if so, proceed normally. Since the lock was not released before, there is no need to re-lock it. If only one thread is using the lock all the time, it is clear that biased locking has little additional overhead and high performance.
- Lightweight locks (spinlocks)
Lightweight lock means that when a biased lock is accessed by another thread, the biased lock will be upgraded to lightweight lock. Other threads will try to acquire the lock through the form of spin, and the thread will not block, thus improving performance. Once a second thread enters the lock contention, the bias lock is upgraded to a lightweight lock (spin lock). If the lock contention continues in the lightweight lock state, the thread that did not grab the lock will spin, that is, constantly loop to determine whether the lock can be successfully acquired. The operation of obtaining the lock is to modify the lock flag bit in the head of the object through CAS. First compares whether the current lock flag bit is “released”, if so it is set to “locked”, and the comparison and setting occurs atomically. The thread then modifies the current lock holder information to itself.
- Heavyweight lock
A heavyweight lock means that when one thread acquires the lock, all other threads waiting to acquire the lock block. If lock contention is serious, a thread that has reached the maximum number of spins will upgrade the lightweight lock to the heavyweight lock (again, the CAS changes the lock flag, but does not change the thread ID that holds the lock). When a subsequent thread tries to acquire the lock and finds that the locked lock is a heavyweight lock, it suspends itself and waits to be woken up in the future.
Ok! This is the end of today’s article, I hope it can be helpful to you, there are wrong places I hope you can put forward, grow together;
Neat makes for great code, and there’s only so much detail