Java-pessimistic lock and optimistic lock

Optimistic lock and pessimistic lock in Java;

1. Java is a typical synchronized is a pessimistic lock, that is, exclusive lock, but JDK1.6 after the synchronized has done a lot of optimization, can not be said to be completely pessimistic lock;

2. Optimistic locking is a kind of thought, that is, read more write less, the likelihood of encountering concurrent writes is relatively low, so take the time to write the version number, and then compare updates. CAS (Compare and Swap) is a typical implementation of optimistic locking. It is important to note that CAS is an idea, not a specific technology.

　　The CAS operation consists of three operands-the memory location (V), the expected original value (A), and the new value (B). If the value V of the memory location matches the expected original value A, the processor automatically updates the location value to the new value B. CAS is an updated atomic operation, in layman's words, is to compare the current value and the incoming value is the same, the same update;

The underlying support is introduced in JDK1.5, especially in the classes in Java.util.concurrent, which have a wide range of applications. CAS operations are exposed on types such as int, long, and object references, and the JVM compiles them into the most efficient method provided by the underlying hardware, and on the platform running CAs, the runtime compiles them into corresponding machine instructions. All of the atomic variable types under the Java.util.concurrent.atomic package, such as Atomicinteger, use these underlying JVM support to provide an efficient CAS operation for reference types of numeric types.

ABA problem: In CAS operation, ABA problems occur.

For example, a thread one takes a from the memory location V, when another thread two also takes a from memory, and two does something to B, and two then turns the data in the V position into a, when the CAS operation finds that the memory is still a, and then the one operation succeeds. Although the CAS operation of thread one is successful, it does not mean that the process is not a problem. This is called the ABA problem.
The simple solution for ABA is to add a version number that updates the value of the reference and version number when it is updated. The ABA problem can be solved by two classes of atomicstampedreference and atomicmarkablereference. Atomicstampedreference Update, check whether the current reference is equal to the expected reference, and then check whether the current identity is equal to the expected identity, equivalent to the indirect reference with a "version number", so as to avoid the ABA problem, Atomicmarkablereference will update an "object reference-Boolean" two-tuple.

The Atomicstampedreference Compareandset method source code is as follows:

/*** atomically Sets the value of both the reference and stamp * to the given update values if the Reference is {@code= =} to the expected reference * and the current stamp are equal to the expected stamp. *     * @paramExpectedreference The expected value of the reference *@paramnewreference The new value for the reference *@paramExpectedstamp The expected value of the stamp *@paramNewstamp The new value for the stamp *@return {@codetrue} if successful*/     Public BooleanCompareandset (v expectedreference, v newreference, intExpectedstamp,intNewstamp) {Pair<V> current =pair; returnexpectedreference= = Current.reference &&Expectedstamp= = Current.stamp &&((newreference= = Current.reference &&Newstamp= = Current.stamp) | |Caspair (Current, Pair.of (Newreference, Newstamp))); }

CAs and synchronized usage scenarios:
1, for less resource competition (less thread conflict), using synchronized synchronization lock for thread blocking and wake-up switching and user-mode kernel state switching operation additional waste of CPU resources, and CAS based hardware implementation, do not need to enter the kernel, do not need to switch threads, The operation spins less often, so you get higher performance.

2, for the serious resource competition (serious thread conflict), the probability of CAS spin is relatively large, thus wasting more CPU resources, efficiency is less than synchronized.

Added: Synchronized has improved its optimization after jdk1.6. Synchronized the underlying implementation of the main rely on the Lock-free queue, the basic idea is the spin after blocking, competition after the switch to continue the competition lock, a little sacrifice of fairness, but achieved high throughput. With fewer thread conflicts, you can get similar performance to CAS, which is much higher than CAs in the case of a severely threaded conflict.

Reference: Http://www.jianshu.com/p/59ddb7002b30

Https://www.cnblogs.com/qjjazry/p/6581568.html

Java-pessimistic lock and optimistic lock