Java-悲观锁和乐观锁

Posted 2020-10-14 骑着乌龟去看海

Java中的乐观锁与悲观锁；

　　1. Java中典型的synchronized就是一种悲观锁，也就是独占锁，不过JDK1.6之后对synchronized已经做了许多优化，也不能说是完全的悲观锁了；

　　2. 乐观锁是一种思想，即认为读多写少，遇到并发写的可能性比较低，所以采取在写的时候先读出版本号，然后比较更新。而CAS(Compare and Swap)即是一种典型的乐观锁的实现。需要注意的是，CAS是一种思想，而不是某一项具体的技术。

　　CAS 操作包含三个操作数 —— 内存位置（V）、预期的原值（A）和新值(B)。如果内存位置的值V与预期原值A相匹配，那么处理器会自动将该位置值更新为新值B。CAS是一种更新的原子操作，通俗的讲，就是比较当前值和传入值是否一样，一样则更新；

　　JDK1.5中引入了底层的支持，特别是在java.util.concurrent中的类中有着广泛的应用。在int、long和对象的引用等类型上都公开了CAS的操作，并且JVM把它们编译为底层硬件提供的最有效的方法，在运行CAS的平台上，运行时把它们编译为相应的机器指令。在java.util.concurrent.atomic包下面的所有的原子变量类型中，比如AtomicInteger，都使用了这些底层的JVM支持为数字类型的引用类型提供一种高效的CAS操作。

ABA问题：在CAS操作中，会出现ABA问题。

　　比如说一个线程one从内存位置V中取出A，这时候另一个线程two也从内存中取出A，并且two进行了一些操作变成了B，然后two又将V位置的数据变成A，这时候线程one进行CAS操作发现内存中仍然是A，然后one操作成功。尽管线程one的CAS操作成功，但是不代表这个过程就是没有问题的。这就是所谓的ABA问题。
　　ABA的简单的解决方案就是增加一个版本号，更新的时候更新引用和版本号的值。AtomicStampedReference和AtomicMarkableReference两个类都可以解决ABA问题。AtomicStampedReference更新的时候，先检查当前引用是否等于预期引用，再检查当前标识是否等于预期标识，相当于间接的给引用加上了“版本号”，从而避免ABA问题，AtomicMarkableReference将更新一个“对象引用-布尔值”的二元组。

AtomicStampedReference的compareAndSet方法源代码如下：

/**
     * Atomically sets the value of both the reference and stamp
     * to the given update values if the
     * current reference is {@code ==} to the expected reference
     * and the current stamp is equal to the expected stamp.
     *
     * @param expectedReference the expected value of the reference
     * @param newReference the new value for the reference
     * @param expectedStamp the expected value of the stamp
     * @param newStamp the new value for the stamp
     * @return {@code true} if successful
     */
    public boolean compareAndSet(V   expectedReference,
                                 V   newReference,
                                 int expectedStamp,
                                 int newStamp) {
        Pair<V> current = pair;
        return
            expectedReference == current.reference &&
            expectedStamp == current.stamp &&
            ((newReference == current.reference &&
              newStamp == current.stamp) ||
             casPair(current, Pair.of(newReference, newStamp)));
    }

CAS与Synchronized的使用情景：　　　
　　1、对于资源竞争较少（线程冲突较轻）的情况，使用synchronized同步锁进行线程阻塞和唤醒切换以及用户态内核态间的切换操作额外浪费消耗cpu资源；而CAS基于硬件实现，不需要进入内核，不需要切换线程，操作自旋几率较少，因此可以获得更高的性能。

　　2、对于资源竞争严重（线程冲突严重）的情况，CAS自旋的概率会比较大，从而浪费更多的CPU资源，效率低于synchronized。

　　补充： synchronized在jdk1.6之后，已经改进优化。synchronized的底层实现主要依靠Lock-Free的队列，基本思路是自旋后阻塞，竞争切换后继续竞争锁，稍微牺牲了公平性，但获得了高吞吐量。在线程冲突较少的情况下，可以获得和CAS类似的性能；而线程冲突严重的情况下，性能远高于CAS。

 

参考：http://www.jianshu.com/p/59ddb7002b30

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