(Add star mark to IT for 15 minutes, you can marry Bai Fumei)
Wechat public number: IT a quarter of an hour large reality non-serious scene a quarter of an hour to share with you high quality technical architecture and knowledge, do a story programmer attention can be the first time to understand more wonderful content, regular welfare to send yo.
So here’s the thing.
So that night, the little brother will hum out the logic of the lock. Its logic, you see the officer to treat me slowly.
Look at a big picture
(Click to see larger version)
Process on
Friendly tip: before reading the following content, it is recommended to read the previous article “And listen to me a story through the principle of synchronized”, so that you can more easily understand the following content.
When the JVM has biased locking enabled (which is enabled by default in JDK6), the Thread Id in the Mark Word of the newly created object is 0. This indicates that the user is in anonymously biased state, but has no bias to any Thread.
Biased lock logic 1. When thread A accesses the synchronous block for the first time, it first detects whether the flag bit in the object header Mark Word is 01, and then determines whether the object lock is in the stateless or biased lock state (anonymous biased lock).
2. Then determine whether the bias lock flag bit is 1. If not, enter the lightweight lock logic (use CAS to compete for locks), if so, enter the next process;
3. Check whether the Thread Id recorded in the object header Mark Word is the current Thread Id. If yes, it indicates that the current Thread has obtained the object lock, and the Thread does not need CAS to lock when it enters the synchronization block. The product can only be added to the stack of the current thread where the product is empty Lock Record, which is used to calculate the number of reentrant (as shown in the figure, when the object is in biased Lock, the current thread reentrant for 3 times, and the Lock Record in the thread stack frame).
When the synchronized block releases biased locks, the corresponding Lock records will be deleted in sequence, but the Thread Id in the object header will not be modified.
Note: Biased lock cancellation refers to the process of changing the lock object to non-biased lock state because conditions are not met in the process of obtaining biased lock, while biased lock release refers to the process of exiting the synchronization block.
4. If the Thread Id in the Mark Word header is not the current Thread Id, the CAS operation is performed to replace the current Thread Id with the Mark Word. If the current object Lock state is in the anonymously biased Lock state (can be biased to unlocked), the replacement will be successful (change the Thread ID in The Mark Word from anonymous 0 to the current Thread ID, find the available Lock Record with the highest memory address in the current Thread stack, store the Thread ID), obtain the Lock, and execute the synchronization code block;
5. If the object lock has been occupied by another thread, it will fail to be replaced and the partial lock cancellation will start, which is also the characteristic of partial lock. Once there is a thread contention, the partial lock will be revoked.
6. The cancellation of the biased locking in need to wait for the global security point (safe point, represents a state, under the condition of all threads are suspended), suspend threads, hold biased locking check hold biased locking thread state (through the current JVM all the threads, if you can find, shows a bias) thread is still alive, and if the thread is still alive Check whether the thread is executing the code in the synchronized code block, if so, upgrade to lightweight lock, CAS contention lock;
Note: The first available Lock Record is found on the stack in descending order each time the monitor enters the block, and the bias thread ID is set. It is removed from the lowest Lock Record each time it is unlocked (i.e., monitorexit). So if the corresponding Lock Record can be found, the biased thread is still executing the code in the synchronized code block.
7. If hold biased locking thread is not alive, or hold a biased locking thread was not synchronized code block in the implementation of the code, then check whether to allow heavy bias, if is not allow bias, the revocation of biased locking, will Mark the status Word is set to do not have a lock (unlocked nor to the state), and then upgrade for lightweight locks, lock for CAS competition;
8. If rebias is allowed and set to anonymous bias lock,CAS will redirect the bias lock to thread A (store the current thread ID in the lock record of the object header and thread stack frame);
9. Wake up the paused thread and resume code execution from a safe point.
That’s the whole logic of biased locking.
The extensions of knowledge
Batch heavy bias and batch cancel origin: From biased locking lock unlock process can be seen, when only one thread enters the synchronized block repeatedly, biased locking performance costs in basic can be ignored, but when there are other threads trying to obtain the lock, need to wait until the safe point, then biased locking revocation is unlocked state or upgrade is lightweight, will consume a certain amount of performance, Therefore, in the case of frequent multi-thread competition, biased locking can not only improve performance, but also lead to performance degradation. Thus, there is a batch rebias and batch undo mechanism.
Bulk rebias is designed to solve the problem that when one thread creates a large number of objects and performs an initial synchronization operation, another thread later operates on those objects as lock objects, resulting in a large number of biased lock rebias operations. Bulk Revoke is designed to address the inappropriate use of partial locks in scenarios where multiple threads are obviously competing.
The principle is to maintain a bias lock undo counter for each class, based on the unit of class. Each time a bias lock is revoked on an object of that class, the counter is +1. When this value reaches the bias threshold (default: 20), the JVM considers the bias lock of that class to be defective and performs batch rebias. Each class object has a corresponding EPOCH field, which is also present in the Mark Word of each object in the biased lock state, and whose initial value is the epoch value in the class when the object was created. Each time a batch rebias occurs, the value is +1, and the stack of all threads in the JVM is traversed to find all biased locks of the class that are being locked, and its EPOCH field is changed to the new value. The next time the lock is acquired, if the epoch of the current object is found to be different from that of the class epoch, the CAS operation will not be performed, even if the current Thread has been biased to another Thread. Instead, the CAS operation will directly change the Mark Word Thread Id of the object to the current Thread Id. When the heavy bias threshold is reached, assuming that the class counter continues to grow, and when it reaches the batch undo threshold (default: 40), the JVM considers the class to be in multithreaded contention, marks the class as unbiased, and then goes straight to lightweight locking logic for that class.
ru guo jue de bu cuo, dian ji yi xia guang gao zhi chi wo yi xia ~
What have we learned from RocketMQ? (NameServer)
Read load balancing in distributed architecture
You are only this article away from solving cache contamination