Shulou(Shulou.com)06/03 Report--

What is the use and underlying principle of Synchronized in Java? in order to solve this problem, this article introduces the corresponding analysis and solution in detail, hoping to help more partners who want to solve this problem to find a more simple and feasible method.

1. Synchronized lock optimization

Efficient concurrency is an important improvement after upgrading from JDK 5 to JDK 6. The HotSpot virtual machine development team spent a lot of resources on this version to implement various lock optimization techniques, such as adaptive spin (Adaptive Spinning), lock elimination (Lock Elimination), lock inflation (Lock Coarsening), lightweight lock (Lightweight Locking), biased lock (Biased Locking) and so on. So as to improve the execution efficiency of the program.

1. Spin lock and adaptive spin

In the previous introduction to threads, it was mentioned that the operations of suspending threads and restoring threads need to be transferred to kernel mode, and frequent switching in user mode and kernel mode is very resource-consuming. Sometimes a thread can finish execution in a short time after acquiring the lock, but it is not worth suspending and resuming the thread for this period of time. You can let the thread that has not acquired the lock wait for a while without giving up the CPU execution time to see if the thread holding the lock will release the lock soon. In order for the thread to wait, we simply have the thread perform a busy loop (spin), a technique known as spin locking.

Spinlock has been introduced in JDK 1.4.2, but it is off by default, can be turned on using the-XX:+UseSpinning parameter, and has been turned on by default in JDK 6. Spin waiting can not replace blocking, not to mention the requirement for the number of processors, although spin waiting itself avoids the overhead of thread switching, it takes up processor time, so if the lock is occupied for a short time, the effect of spin waiting will be very good, on the contrary, if the lock is occupied for a long time, then the spin thread will only consume processor resources, which will lead to a waste of performance. Therefore, the spin waiting time must be limited, and if the spin exceeds the limited number of times and still does not successfully acquire the lock, the thread should be suspended in the traditional way. The default value for the number of spins is ten, and the user can also use the parameter-XX:PreBlockSpin to change the row.

In the optimization of spin lock in JDK 6, adaptive spin is introduced. Adaptation means that the spin time is no longer fixed, but is determined by the spin time of the previous time on the same lock and the state of the lock's owner. If, on the same lock object, spin wait has just successfully acquired the lock, and the thread holding the lock is running, the virtual machine will assume that the spin is likely to succeed again, allowing the spin wait to last relatively longer, such as 100 busy cycles. On the other hand, if the spin rarely succeeds in acquiring the lock for a lock, it is possible to omit the spin process directly to avoid wasting processor resources when acquiring the lock later.

2. Lock elimination

Eliminating lock is another lock optimization of virtual machine, which is more thorough. When Java virtual machine compiles JIT (which can be simply understood as compiling when a piece of code is about to be executed for the first time, it is also called instant compilation), by scanning the running context, it is possible to remove locks that cannot compete for shared resources. In this way, unnecessary locks can be eliminated, which can save meaningless request lock time. The append of the following StringBuffer is a synchronous method, but the StringBuffer in the add method is a local variable and will not be used by other threads, so there can be no competition for shared resources in StringBuffer, and JVM will automatically remove its locks.

Public String concatString (String S1, String S2, String S3) {StringBuffer sb = new StringBuffer (); sb.append (S1); sb.append (S2); sb.append (S3); return sb.toString ();} escape analysis:

Using escape analysis, the compiler can optimize the code as follows:

First, synchronous ellipsis. If an object is found to be accessible only from one thread, synchronization may not be considered for the operation of that object.

Second, convert heap allocation to stack allocation. If an object is allocated in a subroutine, the object may be a candidate for stack allocation rather than heap allocation so that the pointer to the object never escapes.

Third, separate objects or scalar substitution. Some objects may not need to exist as a contiguous memory structure to be accessed, so some (or all) of the objects can be stored not in memory, but in CPU registers.

Do all objects and arrays allocate space in heap memory? Not necessarily. When the Java code is running, you can specify whether to enable escape analysis through the parameter JVM. XX:+DoEscapeAnalysis: enable escape analysis XX:-DoEscapeAnalysis: disable escape analysis. Escape analysis has been enabled by default since jdk 1.7.When enabled, you can use the parameter-XX:+PrintEscapeAnalysis to view the analysis results. With escape analysis support, users can use parameter-XX:+EliminateAllocations to enable scalar substitution, + XX:+EliminateLocks to enable synchronization elimination, and parameter-XX:+PrintEliminateAllocations to view scalar replacement.

Use the following code example to demonstrate the allocation of objects on the stack after opening escape analysis: run time to view the process ID of the program through jps, and then check the number of Student objects through the jmap-histo process ID, you can observe that the number of objects is 500000 when the escape analysis is turned off, while the number of objects after opening the escape analysis is less than 500000, indicating that some Student objects are allocated on the stack rather than on the heap.

Public class StackAllocTest {/ * perform two kinds of tests * turn off escape analysis and adjust the heap space to avoid the occurrence of GC in the heap If any GC information is available, it will be printed * VM operation parameters:-Xmx4G-Xms4G-XX:-DoEscapeAnalysis-XX:+PrintGCDetails-XX:+HeapDumpOnOutOfMemoryError * * enable escape analysis * VM operation parameters:-Xmx4G-Xms4G-XX:+DoEscapeAnalysis-XX:+PrintGCDetails-XX:+HeapDumpOnOutOfMemoryError * * after executing the main method * jps view process * jmap-histo process ID * * / public static void main (String [] args) {long start = System.currentTimeMillis () For (int I = 0; I < 500000; iTunes +) {alloc ();} long end = System.currentTimeMillis (); / / View the execution time System.out.println ("cost-time" + (end-start) + "ms"); try {Thread.sleep (100000);} catch (InterruptedException E1) {e1.printStackTrace () }} private static Student alloc () {/ / Jit will analyze the code escape at compile time / / not all objects are stored in the heap area, some of them have thread stack space Student student = new Student (); return student;} static class Student {private String name; private int age;}} 3, lock coarsening

In principle, when writing code, it is always recommended to limit the scope of synchronization blocks to as little as possible. In most cases, the above principles are correct, but if a series of consecutive operations repeatedly lock and unlock the same object, or even lock operations occur in the body of the loop, even if there is no thread competition, frequent mutually exclusive synchronization operations can also lead to unnecessary performance loss.

This is the case with the continuous append () method of StringBuffer shown in the code example above. If the virtual machine detects such a series of piecemeal operations locking the same object, it will extend (coarsening) the scope of locking synchronization to the outside of the entire operation sequence. Take the above code as an example, it is extended to before the first append () operation until after the last append () operation, so it only needs to be locked once.

Second, object header memory layout

We know that synchronized is locked on an object. How does the object record the lock state? The answer is that the lock state is recorded in the object header (Mark Word) of each object. Let's take a look at the memory layout of the object. For the memory layout of objects, you can first take a look at the following picture, which has been drawn very clearly, and you can see that the area stored in memory can be divided into three parts: object header (Header), instance data (Instance Data) and alignment padding (Padding).

The object header includes two parts of information. The first part is used to store the runtime data of the object itself (also known as "MarkWord"), such as HashCode, GC generational age, lock status flag, lock held by thread, biased thread ID, biased timestamp and so on. The length of this part of data is 32bit and 64bit in 32-bit and 64-bit virtual machines (without compression pointer on). MarkWord is designed as a non-fixed data structure to store as much information as possible in a very small space, and it reuses its own storage space according to the state of the object. For example, in a 32-bit Hotspot virtual machine, if the object is in an unlocked state, the 25bit in MarkWord's 32bit space is used to store the object hash code, the 4bit is used to store the object's generational age, the 2bit is used to store the lock flag bit, and the 1bit is fixed to 0, while in other states (lightweight locking, heavyweight locking, GC marking, biased), the storage content of the object is as follows:

There is a markOop.cpp in the openjdk\ hotspot\ src\ share\ vm\ oops directory in the OpenJDK source code, which defines the storage content in the object header MarkWork. If you are interested, you can take a look at it.

III. The expansion and upgrade process of synchronized lock

There are a total of four lock states, no lock state, bias lock, lightweight lock, and heavy lock. With the competition of locks, locks can be upgraded from biased locks to lightweight locks, and then upgraded heavyweight locks, but the upgrade of locks is one-way, that is, they can only be upgraded from low to high, and there will be no lock degradation.

1. Bias lock

Bias lock is also a lock optimization measure introduced in JDK 6, which aims to eliminate the synchronization primitive of data without competition and further improve the running performance of the program. Biased lock means that the lock will be biased towards the first thread to acquire it, and if the lock has not been acquired by other threads during the rest of execution, the thread holding the biased lock will never need to synchronize again.

Assuming that the current virtual machine has enabled biased locks (enable parameter-XX:+UseBiased Locking, which is the default value for HotSpot virtual machines since JDK 6), when the lock object is first acquired by the thread, the virtual machine will set the flag bit in the object header to "01" and the bias mode to "1" to indicate that it is in biased mode. At the same time, use the CAS operation to record the ID of the thread that acquired the lock in the Mark Word of the object. If the CAS operation is successful, each time the thread holding the lock bias enters the lock-related synchronization block, the virtual machine can no longer perform any synchronization operations (such as locking, unlocking and updating the Mark Word, etc.).

As soon as another thread tries to acquire the lock, the bias pattern ends immediately. According to whether the lock object is currently in a locked state, it is decided whether to undo the bias (the bias mode is set to "0"). After undoing, the flag bit returns to the state of unlocked (flag bit is "01") or lightweight lock (flag bit is "00"). Subsequent synchronization operations are performed as lightweight locks.

The biased lock uses a mechanism that waits for competition to release the lock, so when other threads try to compete for the biased lock, the thread that holds the biased lock releases the lock. The undo of the bias lock requires waiting for the global security point (there is no bytecode being executed at this time). It first pauses the thread that owns the biased lock, then checks whether the thread holding the biased lock is alive, and sets the object header to unlocked if the thread synchronization block has finished executing; if the thread synchronization block is not finished, you need to upgrade the bias lock to a lightweight lock.

When the object enters the biased state, most of the Mark Word space (23 bits) is used to store the lock thread ID, this part of the space occupies the location of the original storage object hash code, what about the original object hash code?

In the Java language, if an object has calculated a hash code, it should always leave this value the same (highly recommended but not mandatory, because users can overload the hashCode () method to return the hash code as they wish), otherwise many API that rely on object hash codes may have the risk of error. The Object::hashCode () method, as the source of the vast majority of object hash codes, returns the object's consistent hash code (Identity Hash Code), which is guaranteed to remain unchanged by storing the calculation result in the object header to ensure that the hash code value obtained by calling the method again will never change after the first calculation. Therefore, when an object has calculated a consistent hash code, it can no longer enter the biased lock state. When an object is currently in a biased lock state and receives a request to calculate its consistency hash code (the calculation request here should come from a call to the Object::hashCode () or System::identityHashCode (Object) method, if the object's hashCode () method is rewritten, the hash code calculation will not produce the request mentioned here), its bias state will be revoked immediately, and the lock will expand into a weight-level lock. In the implementation of the weight lock, the object header points to the location of the weight lock, and there is a field in the ObjectMonitor class that represents the weight lock to record the Mark Word in the unlocked state (flag bit is "01"), in which the original hash code can be stored naturally.

2. Lightweight lock

If the bias lock fails, the virtual machine will not immediately upgrade to a heavy lock, it will also try to use an optimization method called lightweight lock (added after 1.6), and the structure of the Mark Word will also become the structure of a lightweight lock. Lightweight locks can improve program performance on the basis that "there is no competition for most locks throughout the synchronization cycle". Note that this is empirical data. It is important to understand that lightweight locks adapt to situations where threads execute synchronous blocks alternately, and if there is a situation where the same lock is accessed at the same time, it will cause the lightweight lock to expand to a heavy lock.

When the code is about to enter the synchronization block, if the synchronization object is not locked (the lock flag bit is "01"), the virtual machine will first establish a space called lock record (Lock Record) in the stack frame of the current thread, which is used to store the current copy of the lock object's current Mark Word (officially added a Displaced prefix to this copy, that is, Displaced Mark Word). At this time, the state of the thread stack and object header is shown in the following figure.

The virtual machine will then use the CAS operation to attempt to update the object's Mark Word to a pointer to Lock Record. If this update action succeeds, it means that the thread has a lock on the object, and the lock flag bit of the object Mark Word (the last two bits of the Mark Word) will be changed to "00", indicating that the object is in a lightweight locked state. At this point, the state of the thread stack and object header is shown in the following figure.

If this update operation fails, it means that at least one thread competes with the current thread to acquire the lock for the object. The virtual machine will first check whether the Mark Word of the object points to the stack frame of the current thread. If so, it means that the current thread already owns the lock of the object, then go directly to the synchronization block to continue execution, otherwise the lock object has been preempted by other threads. If more than two threads contend for the same lock, the lightweight lock is no longer valid and must be expanded to a heavyweight lock, and the state value of the lock flag becomes "10". At this time, the pointer to the heavyweight lock (mutex) is stored in the Mark Word, and the thread waiting for the lock must also enter the blocking state.

What is described above is the locking process of a lightweight lock, and its unlocking process is also done through the CAS operation. If the object's Mark Word still points to the thread's lock record, replace the object's current Mark Word and the copied Displaced Mark Word in the thread with the CAS operation. If the replacement is successful, the entire synchronization process is completed successfully; if the replacement fails, another thread has tried to acquire the lock, waking up the suspended thread while releasing the lock.

Lightweight locks can improve program synchronization performance on the basis of the rule of thumb that there is no competition for most locks during the whole synchronization cycle. If there is no competition, the lightweight lock successfully avoids the overhead of using mutexes through CAS operations; but if there is lock competition, there is an additional overhead of CAS operations in addition to the cost of mutexes themselves. Therefore, in the case of competition, lightweight locks are slower than traditional heavyweight locks.

3. Weight lock

When the lock is upgraded to a heavy lock, the ObjectMonitor (monitor lock) mentioned above is used. In the markOop.hpp file of the hotspot source code, you can see the following code. When multiple threads access the synchronous code block, it is equivalent to scrambling for the lock identity in the object monitor modified object. The pointer to ObjectMonitor can be obtained through the monitor () method in the object header MarkWord, that is, in the previous example of a 32-bit virtual machine, the first 30 bits of MarkWord became a pointer to ObjectMonitor.

Bool has_monitor () const {return ((value () & monitor_value)! = 0);} ObjectMonitor* monitor () const {assert (has_monitor (), "check"); / / Use xor instead of & ~ to provide one extra tag-bit check. Return (ObjectMonitor*) (value () ^ monitor_value);} 4. Advantages and disadvantages of various locks

Lock

Advantages

Shortcoming

Applicable scenario

Bias lock

Locking and unlocking does not require additional consumption, and there is only a nanosecond gap compared with the execution of asynchronous methods

If there is lock contention between threads, it will lead to additional consumption of lock revocation.

Suitable for scenarios where only one thread accesses the synchronous block

Lightweight lock

Competing threads will not block, which improves the response speed of the program.

If you never get a lock contending thread, using spin consumes CPU

In pursuit of response time, the execution speed of synchronous blocks is very fast and multiple threads execute alternately.

Weight lock

Thread contention is not suitable for spin and will not consume CPU

Thread blocking, slow response time

Scenarios in which throughput is pursued, synchronous blocks take a long time to execute, and multiple thread locks compete fiercely

The answers to the questions about the use of Synchronized in Java and the underlying principles are shared here. I hope the above content can be of some help to you. If you still have a lot of doubts to be solved, you can follow the industry information channel for more related knowledge.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.