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

What is the principle of Sychronized, many novices are not very clear about this, in order to help you solve this problem, the following editor will explain for you in detail, people with this need can come to learn, I hope you can gain something.

Sychronized principle:

(1) upon entry: monitorenter

Each object has a monitor lock (monitor). The monitor is locked when it is occupied, and the thread attempts to take ownership of the monitor when it executes the monitorenter instruction, as follows:

1. If the entry number of monitor is 0, the thread enters monitor, and then sets the entry number to 1, and the thread is the owner of monitor.

2. If the thread already owns the monitor and enters again, the number of entries into the monitor is increased by 1.

3. If another thread has already occupied the monitor, the thread enters a blocking state until the number of entries to the monitor is 0, and then retries to take ownership of the monitor.

(2) when quitting: monitorexit

The thread executing the monitorexit must be the owner of the monitor corresponding to the objectref.

When the instruction is executed, the number of entries of the monitor is minus 1. If the number of entries after minus 1 is 0, the thread exits the monitor and is no longer the owner of the monitor. Other threads blocked by this monitor can try to get this

Ownership of monitor.

Through these two paragraphs, we should be able to clearly see the implementation principle of synchronized. The semantic bottom layer of synchronized is accomplished through a monitor object.

In fact, methods such as wait/notify also rely on monitor objects, which is why methods such as wait/notify can only be called in synchronized blocks or methods, otherwise an exception of java.lang.IllegalMonitorStateException will be thrown.

(3) when synchronized is added to the method:

Judging from the results of decompilation, the synchronization of methods is not accomplished through the instructions monitorenter and monitorexit (which can also be achieved through these two instructions).

Compared with the normal method, it has more ACC_SYNCHRONIZED markers in the constant pool.

JVM synchronizes the method based on this identifier:

When the method is called, the calling instruction will check whether the ACC_SYNCHRONIZED access flag of the method is set. If so, the execution thread will get the monitor first, get the method body successfully, and release the monitor after the method is executed. No other thread can get the same monitor object during method execution. In fact, there is no difference in essence, but the synchronization of methods is achieved in an implicit way, without the need for bytecode.

-

The above is transferred from: https://blog.csdn.net/hbtj_1216/article/details/77773292

JVM optimizes Sychronized:

Locks in synchronized are generally divided into weight locks (object locks), spin locks, adaptive spin locks, lightweight locks and bias locks.

Application scenario of spin lock:

Thread blocking and awakening requires CPU to change from user mode to kernel mentality. Frequent blocking and awakening is a heavy task for CPU, which is bound to bring great pressure to the concurrent performance of the system. At the same time, we find that in many applications, the lock state of the object lock only lasts for a short period of time, so it is not worthwhile to block and wake up the thread frequently in this short period of time, so spin lock is introduced.

If a thread waits for a very short time to acquire a lock object, it is appropriate to use a spin lock. The so-called spin lock is that the thread waiting for the lock does not enter the blocking state, but executes a meaningless loop. Check whether the lock has been released at the end of the loop, and enter the execution state directly if it has been released. Because long meaningless cycles can also waste a lot of system resources, spin locks are suitable for locking scenarios with short intervals.

Adaptive spin lock to adjust the number of spin:

JDK 1.6introduces a smarter spin lock, namely adaptive spin lock. The so-called adaptive means that the number of spins is no longer fixed, it is determined by the spin time of the previous time on the same lock and the state of the lock's owner. If the thread spins successfully, it will spin more times next time, because the virtual machine thinks that since it was successful last time, the spin is likely to succeed again, so it will allow the spin to wait for more times. On the other hand, if few spins are successful for a lock, the number of spins will be reduced or even omitted in the future, so as to avoid wasting processor resources.

Lock elimination

In some cases, JVM detects that there can be no shared data competition, and JVM eliminates these synchronization locks. Lock elimination is based on the data support of escape analysis.

Sometimes we don't show the use of locks, but when we use some of JDK's built-in API, such as StringBuffer, Vector, HashTable, and so on, their internal implementations have invisible locking operations. Such as the append () method of StringBuffer and the add () method of Vector.

When running this code, JVM can clearly detect that the variable vector does not escape from the method vectorTest (), so JVM can boldly eliminate locking operations within vector.

Lock coarsening

We know that when using synchronization locks, we need to keep the scope of synchronization blocks as small as possible-synchronizing only in the actual scope of shared data, in order to minimize the number of operations that need to be synchronized as much as possible. if there is lock competition, the thread waiting for the lock can get the lock as soon as possible.

In most cases, the above view is correct. However, if a series of continuous locking and unlocking operations, it may lead to unnecessary performance loss, so the concept of lock foul language is introduced.

Lock coarsening is to connect multiple continuous locking and unlocking operations together and expand into a larger range of locks. For example, vector requires locking every time it add. JVM detects that continuous locking and unlocking operations on the same object (vector) will merge a larger range of locking and unlocking operations, that is, locking and unlocking operations will move outside the for loop.

Lightweight lock and bias lock:

It is suitable for situations where there is no thread competition. Can't replace weight lock.

Weight lock:

The heavyweight lock is realized by the monitor (monitor) inside the object, in which the essence of monitor depends on the Mutex Lock implementation of the underlying operating system. The switching between threads in the operating system needs to switch from user mode to kernel state, and the switching cost is very high.

(3) the above locks are implemented internally by JVM itself. When we execute the synchronized synchronization block, jvm will decide how to perform the synchronization operation according to the enabled lock and the contention of the current thread.

When all locks are enabled, the thread will first acquire the bias lock when it enters the critical area. If there is already a bias lock, it will try to acquire the lightweight lock. If both of the above two types fail, the spin lock is enabled. If the spin does not acquire the lock, the heavy lock is used, and the thread that does not acquire the lock is blocked and suspended until the thread holding the lock wakes them up after executing the synchronization block.

Bias lock-- "lightweight lock--" spin lock-"heavyweight lock

Is it helpful for you to read the above content? If you want to know more about the relevant knowledge or read more related articles, please follow the industry information channel, thank you for your support.

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.