background
We operate in multiple properties cpu execution is not interrupted called atomic. The cpu switch occurred on cpu command level, so the thread switching problem caused by the atom. So if we ban cpu switch work? The answer is no, because in the case of multi-core, if there are two threads of the same cpu time operation with a variable, not even a thread switch occurs, each cpu their execution error (such as execution count ++ operation will take place, each cpu executed The results may have been 1). The essence of the problem is that there are multiple threads execute the operation undermine the atomic Meanwhile, if we can guarantee that only one thread of execution, that is serial execution, so you can guarantee atomicity. The solution is to mutex
java in lock: synchronized
- synchronized keyword java provides, is a lock to achieve. The method can be used to modify, can also be used to modify the code block.
- The compiler at compile-time modification of the method of synchronized code block or lock and unlock operation is automatically added.
- Note: When modifying a static method, the lock is the current Class object, when a non-static methods for modifying, locked the current instance of the object this
- Visibility: The principle of HB, HB unlocking operation of the lock in a subsequent locking operation on the lock, combined delivery principle HB, modifications variable (the operation again before a thread lock on the critical region can be shared before), after a subsequent thread enters a critical region (the re-lock operation) is visible
The principle of synchronized
synchronized code block is achieved by a pair of monitorenter / monitorexit instruction, the synchronized method is achieved by ACC_SYNCHRONIZED identifier, whether monitorenter / exit command or ACC_SYNCHRONIZED is achieved by acquiring ownership of the Monitor.
Monitor implementation principle process is as follows:
- Monitorenter instruction execution thread, into the monitor if the number is 0, the thread enters the monitor, and then enter the number is set to 1, the thread is the owner of the monitor; if the thread has occupied the monitor, only to re-enter, then enter the monitor enter the number plus one. If another thread has occupied the monitor, the thread enters the blocked state, and into entryList. If a thread is blocked to acquire a lock wait method, then transferred to waitSet collection, if at some point notify or notifyAll wake up, it enters the entryList again, waiting to re-acquire the lock
- When executed monitorexit, enter the monitor number minus 1, minus 1 if entered number is 0, then the thread exits monitor, it is no longer the owner of this monitor. Then entrylist threads can try to acquire ownership of the moniter
Before Java 6, Monitor is implemented within the operating system rely mutex because the user mode and kernel mode switching needs, synchronous operation is a heavyweight operation
Modern JDK in, jvm provides three different monitor implementation, which is often said deflection locks, lock lightweight, heavyweight lock. The so-called lock upgrade, downgrade, jvm optimization is synchronized mechanism, when the detected jvm to a different state, switches to achieve a suitable lock