Java 乐观锁和悲观锁

Posted 2023-04-01 WYSCODER

文章目录

• Java 乐观锁和悲观锁
• • 1、悲观锁
  • 2、乐观锁
  • • 2.1 CAS
    • 2.2 模拟CAS算法
    • 2.3 JUC
    • 2.4 CAS中的ABA问题
    • 2.5 使用CAS会引发的问题

---

Java 乐观锁和悲观锁

1、悲观锁

总是假设最坏的情况，每次在去获取共享数据的时候都认为别人会修改，所以每次都在获取数据的时候加锁。 传统的关系型数据库里就用到很多这种锁，比如行锁，表锁、读锁、写锁等都是在操作之前先上锁，比如java中Synchronized关键字的实现也是悲观锁。

悲观锁存在的问题

在多线程竞争下，加锁，释放锁会导致比较多的上下文切换和调度延迟，引起性能问题一个线程持有锁会导致其他需要此锁的线程挂起

2、乐观锁

认为数据一般情况下不会产生并发冲突，所以在数据进行提交更新的时候，才会对数据是否产生并发冲突进行检测，如果发现并发冲突，则返回错误信息，需要用户去决定如何操作。乐观锁实现的典型是CAS（Compare and Swap）

2.1 CAS

具有原子特性
CAS是乐观锁的实现技术，当多个线程尝试使用CAS同时更新同一个变量，只有一个线程能更新变量的值，而其他的线程都失败，失败的线程不会被挂起，而是被告知这次竞争失败了，并可以再次进行尝试。

CAS操作中涉及三个操作数：
● 需要读写的内存位置（V）
● 需要比较的预期原值（A）
● 拟写入的新值（B）

如果内存位置V的值与预期原值A相匹配，那么处理器会自动的将该位置值更新为B，否则处理器不做任何处理。
第一步： 获取位置V的值A
第二步： 将获取的值A和位置V的内容进行比较，如果相等，认为没有其他线程修改该位置，即不存在并发竞争，就可以将新值B写入位置V。如果不相等，说明存在其他的线程在对该位置进行并发操作。不能直接修改，继续跳转第一步，获取位置V的值，再进行比较，直至相等再修改为B。

2.2 模拟CAS算法

CompareAndSwap类

public class CompareAndSwap 
    private int value;

    //获取内存值
    public synchronized int getValue() 
        return value;
    

    //比较并交换
    public synchronized int compareAndSwap(int expectedValue, int newValue) 
        int oldValue = value;
        //如果内存值和预期值一致，就替换
        if (oldValue == expectedValue) 
            this.value = newValue;
        

        return oldValue;
    

    //设置调用比较并交换， 看期望值和原来的值是否一致
    public synchronized boolean compareAndSet(int expectValue, int newValue) 
        return expectValue == compareAndSwap(expectValue, newValue);
    

TestCAS类

import java.util.Random;

public class TestCAS 
    public static void main(String[] args) 
        CompareAndSwap compareAndSwap = new CompareAndSwap();

        for (int i = 0; i < 10; i++) 
            new Thread(new Runnable() 
                @Override
                public void run() 
                    Random random = new Random();
                    int expectedValue = compareAndSwap.getValue();
                    int newValue = random.nextInt(100);
                    boolean b = compareAndSwap.compareAndSet(expectedValue, newValue);
                    System.out.println("线程：" + Thread.currentThread().getName() + ",预期值：" + expectedValue + ",待写入值："  + newValue + ",操作结果：" + b);
                
            ).start();
        
    

运行结果：

2.3 JUC

在JDK 1.5中新增了java.util.concurrent（J.U.C）建立在CAS之上，相对于Synchronized是一种线程阻塞处理，CAS是非阻塞的一种常见实现，及线程即使没有获取到变量，也不会进入到阻塞状态。就是在不使用锁的情况下来保证线程安全，在JUC下存在如AtomicInteger为例，其中一些++i操作是安全性操作，如getAndIncrement方法。

代码示例：

public class TestJUC 
    public static void main(String[] args) 
        AtomicInteger atomicInteger = new AtomicInteger();
        for (int i = 0; i < 10; i++)
            new Thread(new Runnable() 
                @Override
                public void run() 
                    int i = atomicInteger.getAndIncrement();
                    System.out.println(Thread.currentThread().getName() +
                            "，预期值：" + i);
                
            ).start();
    

运行结果：

2.4 CAS中的ABA问题

CAS会引起ABA的问题，假如存在如下执行序列：

1、线程1从内存中V取出A
2、线程2从内存中V取出A
3、线程2进行了一些操作，将B写入位置V。
4、线程2将A再次写入位置V
5、线程1进行CAS操作，发现位置V依然是A，进行修改操作并成功
6、尽管线程1的CAS操作成功，但不代表这个过程没有问题，对于线程1，线程2的修改已经丢失了。

一个链表ABA的问题：

1、 现有一个单向链表实现的堆栈，栈顶为A。这时线程1已经知道A.next是B，希望通过CAS操作将栈顶替换为B，线程1执行compareAndSwap（A,B）
2、 在线程1执行上面指令之前，线程2介入，将A、B出栈，在依次入栈D、C、A，而对象B次数处于游离状态。
3、 此时线程1执行CAS操作，检测栈顶认为A，所以CAS成功，栈顶是B，但实际B.next为null,此时堆栈中只有一个B元素，C和D组成的链表就不存在在堆栈中，C、D被丢弃了

ABA问题的解决

ABA问题的解决思路就是使用版本号，在变量上追加一个版本号，每次变量变更把版本号加1，那么A-B-A就回去变成1A-2B-3A。

2.5 使用CAS会引发的问题

使用CAS好处就是被使用锁的开销要小，但存在问题

• ABA的问题
  ABA的问题的解决方案是加版本号解决
• 循环时间开销大
  如果CAS如果长时间不成功，会给CPU带来非常大的执行开销
• 只能保证一个共享变量的原子操作
  当对一个共享变量执行操作时，可以使用循环CAS的方式保证原子操作，但对于多个共享变量，循环CAS就无法保证操作的原子性，这个时候就需要借助于锁来实现

Java-悲观锁和乐观锁

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