Prior to JDK 1.6, the cost synchonized synchronized manner is very high, because of the use kernel mode and user mode switching system calls caused by the thread in the obstruction caused by switching. But behind the improvement, the introduction of the four states locks, are no lock, tend to lock, lock lightweight, heavyweight lock, but only step by step expansion.
But when I was new to the expansion process has been very tangled, and later figured it out, now pumping a time to sum up the record about.
First of all we need to know, this situation applies several levels.
- Biased locking: apply to only one thread into the sync area
- Lightweight lock: for synchronizing multiple threads alternately into the area
- Heavyweight lock: for synchronizing multiple threads at the same time to enter the competition area
I will not go into details about the specific three of them directly to explain how the expansion.
- When a thread (assuming A thread called) want to get the lock, lock flag is first checked in the object header, if the lock is biased, then jump to 2, if the locked state is no, then jump to 3.
- Deflecting thread id examination subject header is pointing to the thread A, it is performed directly block the synchronization code, is not 3.
- Use cas deflecting thread id will replace the object header, successful sync block is directly performed. Fails then the other thread (assuming that thread called B) has been biased lock, then be biased locking revocation (because there is a competition), then execute 4.
- B thread running to the global security points, to suspend the thread, check its status, if inactive or has exited the synchronization code block is the original holders biased locking thread releases the lock, and then re-execute A 3. If you are still active, you need to upgrade to a lightweight lock, then perform 5.
- Assigned in the locks B thread stack, to lock MarkWord copy target recording head, and then to point B MarkWord threads, while the object header locks the lock flag information 00 to the lightweight, and then wake up B thread, that is, execution continues at the security point.
- Since the lock lock escalation is lightweight, A thread performs the same operation, i.e., the dispensing lock record A thread's stack, the copy of the object header Mark Word to lock record, and then replace the use MarkWord cas operation since this when B thread owns the lock, therefore, A spin thread. If successful spin lock within a certain number of times, then A lightweight thread gets the lock, perform synchronized block. If the spin not been locked, A heavyweight lock upgrade, the object header to a lock flag information heavyweight 10, while blocking, see 7 at this time.
- B thread releases the lock when using cas information MarkWord replaces successful, it means no competition (this time is a lightweight lock, A thread might spin in) direct release. Failure (because this time the lock has been expanded), then wakes up the suspended thread (in this case, that is, A) after release.
The above is my understanding of lock expansion process. The wrong place, please correct me.
Here to add some additional knowledge :
Spin locks , that is, if the thread holding the lock can be very short period of time to release the lock, then the competition will not need to enter the lock thread blocked pending, but wait a minute (spin), so users can avoid thread and kernel thread switching overhead, but if more than a certain time has not yet been, or will enter the obstruction.
By spin locks, you can reduce the thread switching thread is blocked due (including suspend and resume a thread threads).
After 1.6 introduces adaptive spin lock is in a locked state with spin lock time and the owner is determined by the previous.
Adaptive spin solution is to "lock contention indefinite time" issue . JVM is difficult to perceive the exact time of lock contention, and to analyze user violates the JVM is designed. Adaptive spin assume the same time a different thread holds the lock object is roughly equal, the degree of competition tends to be stable, and therefore, according to the last spin time and a spin at the results of the adjustment time.
Each lock Applicable scene:
Here I use to sum up "java concurrent programming art" in
| lock | advantage | Shortcoming | Applicable scene |
|---|---|---|---|
| Biased locking | Locking and unlocking no additional consumption, and perform asynchronous method there is only nanosecond gap ratio | If there is lock contention between threads, it will bring additional lock revocation consumption | It applies to only one thread synchronization block access to scenes |
| Lightweight lock | The thread does not block competition, improve the response speed of the procedure | If still unable to get the spin lock contention threads consumes CPU | The pursuit of response time, lock occupies a very short time |
| Heavyweight lock | Thread competition is not using a spin, do not consume CPU | Thread is blocked, slow response time | The pursuit of throughput, lock takes a long time |