乐观锁和悲观锁的优缺点与适用场景

最新推荐文章于 2024-04-30 17:28:01 发布

白痴鱼

最新推荐文章于 2024-04-30 17:28:01 发布

阅读量4.4k

点赞数 7

文章标签： java

本文链接：https://blog.csdn.net/sinat_32421529/article/details/104992791

版权

一、基本概念

乐观锁和悲观锁是两种思想，用于解决并发场景下的数据竞争问题。

乐观锁：是一种基于冲突检测的方法，检测到冲突时操作就会失败。在操作数据时非常乐观，认为别人不会同时修改数据。因此乐观锁不会上锁，只是在执行更新的时候判断一下在此期间别人是否修改了数据：如果别人修改了数据则放弃操作，否则执行操作。

悲观锁：悲观锁在操作数据时比较悲观，认为别人会同时修改数据。因此操作数据时直接把数据锁住，直到操作完成后才会释放锁；上锁期间其他人不能修改数据。

二、实现方式(含实例)

在说明实现方式之前，需要明确：乐观锁和悲观锁是两种思想，它们的使用是非常广泛的，不局限于某种编程语言或数据库。

悲观锁的实现方式是加锁，加锁既可以是对代码块加锁（如Java的synchronized关键字），也可以是对数据加锁（如MySQL中的排它锁）。

乐观锁的实现方式主要有两种：CAS机制和版本号机制

2.1、CAS（Compare And Swap）

CAS操作包括了3个操作数：
需要读写的内存位置(V) 进行比较的预期值(A) 拟写入的新值(B)

CAS操作逻辑如下：
如果内存位置V的值等于预期的A值，则将该位置更新为新值B，否则不进行任何操作。
许多CAS的操作是自旋的：如果操作不成功，会一直重试，直到操作成功为止。

这里引出一个新的问题，既然CAS包含了Compare和Swap两个操作，它又如何保证原子性呢？
答案是：CAS是由CPU支持的原子操作，其原子性是在硬件层面进行保证的。

下面以Java中的自增操作(i++)为例，看一下悲观锁和CAS分别是如何保证线程安全的。

在Java中自增操作不是原子操作，它实际上包含三个独立的操作：
读取i值；加1；将新值写回i

因此，如果并发执行自增操作，可能导致计算结果的不准确。在下面的代码示例中：value1没有进行任何线程安全方面的保护，value2使用了乐观锁(CAS)，value3使用了悲观锁(synchronized)。

运行程序，使用1000个线程同时对value1、value2和value3进行自增操作，可以发现：value2和value3的值总是等于1000，而value1的值常常小于1000。

public class Test {

    //value1：线程不安全
    private static int value1 = 0;
    
    //value2：使用乐观锁
    private static AtomicInteger value2 = new AtomicInteger(0);
    
    //value3：使用悲观锁
    private static int value3 = 0;
    
    private static synchronized void increaseValue3(){
        value3++;
    }

    public static void main(String[] args) throws Exception {
        //开启1000个线程，并执行自增操作
        for(int i = 0; i < 1000; ++i){
            new Thread(new Runnable() {
                @Override
                public void run() {
                    try {
                        Thread.sleep(100);
                    } catch (InterruptedException e) {
                        e.printStackTrace();
                    }
                    value1++;
                    value2.getAndIncrement();
                    increaseValue3();
                }
            }).start();
        }
        
        //打印结果
        Thread.sleep(1000);
        System.out.println("线程不安全：" + value1);
        System.out.println("乐观锁(AtomicInteger)：" + value2);
        System.out.println("悲观锁(synchronized)：" + value3);
    }
}

首先来介绍AtomicInteger。AtomicInteger是java.util.concurrent.atomic包提供的原子类，利用CPU提供的CAS操作来保证原子性；除了AtomicInteger外，还有AtomicBoolean、AtomicLong、AtomicReference等众多原子类。

下面看一下AtomicInteger的源码，了解下它的自增操作getAndIncrement()是如何实现的（源码以Java7为例，Java8有所不同，但思想类似）。

public class AtomicInteger extends Number implements java.io.Serializable {

    //存储整数值，volatile保证可视性
    private volatile int value;
    
    //Unsafe用于实现对底层资源的访问
    private static final Unsafe unsafe = Unsafe.getUnsafe();

    //valueOffset是value在内存中的偏移量
    private static final long valueOffset;
    
    //通过Unsafe获得valueOffset
    static {
        try {
            valueOffset = unsafe.objectFieldOffset(AtomicInteger.class.getDeclaredField("value"));
        } catch (Exception ex) { throw new Error(ex); }
    }

    public final boolean compareAndSet(int expect, int update) {
        return unsafe.compareAndSwapInt(this, valueOffset, expect, update);
    }

    public final int getAndIncrement() {
        for (;;) {
            int current = get();
            int next = current + 1;
            if (compareAndSet(current, next))
                return current;
        }
    }
}

源码分析说明如下：

getAndIncrement()实现的自增操作是自旋CAS操作：在循环中进行compareAndSet，如果执行成功则退出，否则一直执行。
其中compareAndSet是CAS操作的核心，它是利用Unsafe对象实现的。
Unsafe又是何许人也呢？Unsafe是用来帮助Java访问操作系统底层资源的类（如可以分配内存、释放内存），通过Unsafe，Java具有了底层操作能力，可以提升运行效率；强大的底层资源操作能力也带来了安全隐患(类的名字Unsafe也在提醒我们这一点)，因此正常情况下用户无法使用。AtomicInteger在这里使用了Unsafe提供的CAS功能。
valueOffset可以理解为value在内存中的偏移量，对应了CAS三个操作数(V/A/B)中的V；偏移量的获得也是通过Unsafe实现的。
value域的volatile修饰符：Java并发编程要保证线程安全，需要保证原子性、可视性和有序性；CAS操作可以保证原子性，而volatile可以保证可视性和一定程度的有序性；在AtomicInteger中，volatile和CAS一起保证了线程安全性。关于volatile作用原理的说明涉及到Java内存模型(JMM)，这里不详细展开。

说完了AtomicInteger，再说synchronized。synchronized通过对代码块加锁来保证线程安全：在同一时刻，只能有一个线程可以执行代码块中的代码。synchronized是一个重量级的操作，不仅是因为加锁需要消耗额外的资源，还因为线程状态的切换会涉及操作系统核心态和用户态的转换；不过随着JVM对锁进行的一系列优化(如自旋锁、轻量级锁、锁粗化等)，synchronized的性能表现已经越来越好。

2.2、版本号机制(数据版本Version记录机制)

除了CAS，版本号机制也可以用来实现乐观锁。版本号机制的基本思路是：
读取出数据时，将此版本号一同读出，之后更新时，对此版本号加一。此时，将提交数据的版本数据与数据库表对应记录的当前版本信息进行比对，如果提交的数据版本号大于数据库表当前版本号，则予以更新，否则认为是过期数据。

需要注意的是，这里使用了版本号作为判断数据变化的标记，实际上可以根据实际情况选用其他能够标记数据版本的字段，如时间戳等。

假设数据库中帐户信息表中有一个 
version 字段，当前值为 1 ；而当前帐户余额字段（ balance ）为 $100 。 
1  操作员 A 此时将其读出（ version=1 ），并从其帐户余额中扣除 $50 
 （ $100-$50 ）。 
2  在操作员 A 操作的过程中，操作员 B 也读入此用户信息（ version=1 ），并 
   从其帐户余额中扣除 $20 （ $100-$20 ）。 
3 操作员 A 完成了修改工作，将数据版本号加一（ version=2 ），连同帐户扣 
  除后余额（ balance=$50 ），提交至数据库更新，此时由于提交数据版本大 
  于数据库记录当前版本，数据被更新，数据库记录 version 更新为 2 。 
4 操作员 B 完成了操作，也将版本号加一（ version=2 ）试图向数据库提交数 
  据（ balance=$80 ），但此时比对数据库记录版本时发现，操作员 B 提交的 
  数据版本号为 2 ，数据库记录当前版本(再查一遍该记录)也为 2 ，不满足 “ 提交版本必须大于记 
  录当前版本才能执行更新 “ 的乐观锁策略，因此，操作员 B 的提交被驳回。 
  这样，就避免了操作员 B 用基于 version=1 的旧数据修改的结果覆盖操作 
  员 A 的操作结果的可能。 

  从上面的例子可以看出，乐观锁机制避免了长事务中的数据库加锁开销（操作员 A 
和操作员 B 操作过程中，都没有对数据库数据加锁），大大提升了大并发量下的系 
统整体性能表现。

三、优缺点和适用场景

乐观锁和悲观锁并没有优劣之分，它们有各自适合的场景；下面从两个方面进行说明。

3.1、功能限制

与悲观锁相比，乐观锁适用的场景受到了更多的限制，无论是CAS还是版本号机制。

例如，CAS只能保证单个变量操作的原子性，当涉及到多个变量时，CAS是无能为力的，而synchronized则可以通过对整个代码块加锁来处理。再比如版本号机制，如果query的时候是针对表1，而update的时候是针对表2，也很难通过简单的版本号来实现乐观锁。

3.2、竞争激烈程度

如果悲观锁和乐观锁都可以使用，那么选择就要考虑竞争的激烈程度：

当竞争不激烈 (出现并发冲突的概率小)时，乐观锁更有优势，因为悲观锁会锁住代码块或数据，其他线程无法同时访问，影响并发，而且加锁和释放锁都需要消耗额外的资源。

当竞争激烈(出现并发冲突的概率大)时，悲观锁更有优势，因为乐观锁在执行更新时频繁失败，需要不断重试，浪费CPU资源。

四、问：乐观锁加锁吗？

乐观锁本身是不加锁的，只是在更新时判断一下数据是否被其他线程更新了；AtomicInteger便是一个例子。
有时乐观锁可能与加锁操作合作，例如，在前述updateCoins()的例子中，MySQL在执行update时会加排它锁。但这只是乐观锁与加锁操作合作的例子，不能改变“乐观锁本身不加锁”这一事实。

五、问：CAS有哪些缺点？

下面是CAS一些不那么完美的地方：

5.1、ABA问题

假设有两个线程——线程1和线程2，两个线程按照顺序进行以下操作： (1)线程1读取内存中数据为A； (2)线程2将该数据修改为B； (3)线程2将该数据修改为A； (4)线程1对数据进行CAS操作
在第(4)步中，由于内存中数据仍然为A，因此CAS操作成功，但实际上该数据已经被线程2修改过了。这就是ABA问题。

在AtomicInteger的例子中，ABA似乎没有什么危害。但是在某些场景下，ABA却会带来隐患，例如栈顶问题：一个栈的栈顶经过两次(或多次)变化又恢复了原值，但是栈可能已发生了变化。
对于ABA问题，比较有效的方案是引入版本号，内存中的值每发生一次变化，版本号都+1；在进行CAS操作时，不仅比较内存中的值，也会比较版本号，只有当二者都没有变化时，CAS才能执行成功。Java中的AtomicStampedReference类便是使用版本号来解决ABA问题的。

5.2、高竞争下的开销问题

在并发冲突概率大的高竞争环境下，如果CAS一直失败，会一直重试，CPU开销较大。针对这个问题的一个思路是引入退出机制，如重试次数超过一定阈值后失败退出。当然，更重要的是避免在高竞争环境下使用乐观锁。

5.3、功能限制

CAS的功能是比较受限的，例如CAS只能保证单个变量（或者说单个内存值）操作的原子性，这意味着：(1)原子性不一定能保证线程安全，例如在Java中需要与volatile配合来保证线程安全；(2)当涉及到多个变量(内存值)时，CAS也无能为力。

除此之外，CAS的实现需要硬件层面处理器的支持，在Java中普通用户无法直接使用，只能借助atomic包下的原子类使用，灵活性受到限制。

参考：

https://www.jianshu.com/p/98698f4d6d2b

https://www.jianshu.com/p/6e4005acb4e3

白痴鱼

关注

7
点赞
踩
21

收藏

觉得还不错? 一键收藏
2
评论
乐观锁和悲观锁的优缺点与适用场景

目录基本概念实现方式(含实例)优缺点和适用场景问题：乐观锁加锁吗？问题：CAS有哪些缺点？一、基本概念乐观锁和悲观锁是两种思想，用于解决并发场景下的数据竞争问题。乐观锁：是一种基于冲突检测的方法，检测到冲突时操作就会失败。在操作数据时非常乐观，认为别人不会同时修改数据。因此乐观锁不会上锁，只是在执行更新的时候判断一下在此期间别人是否修改了数据：如果别人修改了数据则放弃操作，否则执行...
复制链接

扫一扫