Is Java lightweight lock faster than heavyweight lock?
Today, I would like to share with you the relevant knowledge of Java lightweight locks faster than heavyweight locks. The content is detailed and the logic is clear. I believe most people still know too much about this knowledge, so share this article for your reference. I hope you can get something after reading this article. Let's take a look at it.
Lock concept
Lightweight lock is a new concept of JDK 1.6. it is only a state relative to the traditional heavy lock. Synchronized needs to be implemented through the mutex lock of the operating system itself in JDK 1.5. however, this implementation needs to be realized by switching between user state and kernel state, but this switching process will bring great performance overhead. So lightweight locks were introduced in JDK 1.6 to avoid this problem.
Lightweight lock execution process
Before we talk about the lightweight lock execution process, let's start with the object header of the virtual machine. The object header (Object Header) of HotSpot is divided into two parts:
The Mark Word area, which is used to store the object's own run-time data, such as HashCode, GC zoning age, etc., and a pointer to the method area object type data (and, in the case of an array object, additional information about the length of the array).
Mark Word has 32bit space in a 32-bit system, where:
25bit is used to store the zoning age of objects used by HashCode;4bit; 2bit is used to store lock flag bits, 01 = biased lock, 00 = lightweight lock, 10 = heavyweight lock; 1bit is fixed to 0.
In addition, the execution process of lightweight lock, when the code enters the synchronization block, if the object is not occupied by the thread, the virtual machine first copies the stack frame of this thread and stores it in the Lock Record (lock record) area of the current object.
Then the virtual machine uses CAS (Compare and Swap, compare and swap) to update the Mark Word of the thread to a pointer to the Lock Record area of the object. If the update is successful, it means that the thread owns the object, and the lightweight lock is added successfully. If the update fails, the virtual machine first checks whether the object Mark Word points to the wire frame of the current thread. If so, it indicates that the thread already owns the lock, if not. Indicates that the lock is already occupied by another thread. If more than two threads are competing for a deadlock, the lock will swell into a weight lock, and the mutex pointer to the weight lock is stored in Mark Word, and the thread waiting for the lock will also enter a blocking state.
From the above process, we can see that lightweight locks can be understood as implemented through CAS. Ideally, there is no lock competition in the whole synchronization cycle, so lightweight locks can effectively improve the synchronization performance of the program. However, if, on the contrary, lightweight locks bear not only the cost of CAS but also the cost of mutex, in this case lightweight locks will be slower than heavyweight locks This is the answer of our article.
That's all about the article "is Java lightweight Lock faster than heavyweight Lock?" Thank you for reading! I believe you will gain a lot after reading this article. The editor will update different knowledge for you every day. If you want to learn more knowledge, please pay attention to the industry information channel.
