There are not only black and white in the world, there are gray areas between black and white.

In the adult world, most people like black or white point of view to look at a problem, such as “12 citizens” in the beginning all that must be rich second generation “S kill his own father”, in the end we found after rational analysis and speculation, it is not 99.99% most people think. We are easily misled by others’ words, believe what we want to believe, listen to what we want to hear, and then dominated by public opinion, gradually lose ourselves in the chorus, and then lose their ability to think independently.

Learning technology is the same, do not believe the book, thinking is the purpose of learning, if reading is not to inspire their own wisdom, just to blow NB, then this person has a great probability will accomplish nothing.

Now let’s come back to the question: are lightweight locks faster than weight locks?

The answer

Before answering this question, let’s first understand what a lightweight lock is. What is a heavyweight lock?

Lock the concept

In JDK 1.5, synchronized was implemented using the operating system’s own mutex lock. However, this implementation requires switching between the user state and the core state, which is a performance overhead, so lightweight locking was introduced in JDK 1.6 to avoid this problem.

Lightweight lock execution process

Before we go into the lightweight locking process, we need to start with the Object Header of the virtual machine. The Object Header of HotSpot has two parts:

  1. The Mark Word area is used to store the runtime data of the object itself, such as HashCode, GC banding age, etc.
  2. A pointer to the type of the method area object (and, in the case of an array object, an additional information to store the length of the array).

Mark Word on a 32-bit system, has 32bit space, where:

  • 25bit is used to store HashCode;
  • 4bit is used to store the banding age of the object.
  • 2bit is used to store lock flag bits, 01= bias lock, 00= lightweight lock, 10= heavyweight lock;
  • 1bit is fixed to 0.

When code enters a synchronized block, if the object is not occupied by a thread, the virtual machine copies the thread’s stack frame and stores it in the Lock Record area of the current object.

Then the VIRTUAL machine uses CAS (Compare and Swap) to update the thread’s Mark Word to the pointer pointing to the Lock Record area of the object. If the update succeeds, it means that the thread owns the object, and the lightweight Lock is added successfully. If the update fails, The virtual machine first checks to see if the object Mark Word points to a line frame of the current thread. If it does, it indicates that the thread already owns the lock. If it does not, it indicates that the lock has been occupied by another thread. If more than two threads are fighting for a deadlock, the lock will swell to a weight lock. The Mutex pointer to the weight lock will be stored in Mark Word, and any thread waiting for the lock will block.

As we can see from the above, the process of the lightweight lock can be understood as are implemented by CAS, the ideal situation is there is no lock contention, the synchronous cycle so lightweight lock can effectively improve the synchronization performance of the program, however, if the situation on the contrary, lightweight lock not only should shoulder the cost of CAS to shoulder the cost of the mutex, In this case, lightweight locks are slower than weight locks, which is the answer for this article.

conclusion

A lightweight lock is not necessarily faster than a weight lock, depending on whether multiple threads preemption resources during the synchronized block execution. If so, the performance cost of a CAS + mutex lock on a lightweight thread is slower than that of a weight lock.

The same is true of good and bad and right and wrong. It’s not always true. Something may be right today, but it may be wrong tomorrow. For example, in JDK 1.5, you could say that there was only one way to synchronize threads: synchronized, whereas in JDK 1.6, Lock was added, and what you said yesterday may be wrong tomorrow. So right and wrong is not so absolute, it is not so important, the important thing is that you have to have the ability to think independently and recognize right and wrong.

Follow the qr code below and subscribe for more awesome content.