java中的锁:你了解乐观锁和悲观锁吗？

时间  2019-11-16 标签 java 中 锁 了解 乐观 锁 悲观 锁

前言

  • 乐观锁和悲观锁问题，是出现频率比较高的面试题。
  • 本文将由浅入深，逐步介绍它们的基本概念、实现方式(含实例)、适用场景。

1、基本概念

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

乐观锁：乐观锁在操做数据时很是乐观，认为别人不会同时修改数据。面试

所以乐观锁不会上锁，只是在执行更新的时候判断一下在此期间别人是否修改了数据：若是别人修改了数据则放弃操做，不然执行操做。数据库

悲观锁：悲观锁在操做数据时比较悲观，认为别人会同时修改数据。编程

所以操做数据时直接把数据锁住，直到操做完成后才会释放锁；上锁期间其余人不能修改数据。windows

2、实现方式(含实例)

在说明实现方式以前，须要明确：乐观锁和悲观锁是两种思想，它们的使用是很是普遍的，不局限于某种编程语言或数据库。安全

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

乐观锁的实现方式主要有两种：CAS机制和版本号机制，下面详细介绍。并发

  1. CAS（Compare And Swap）

CAS操做包括了3个操做数：编程语言

1) 须要读写的内存位置(V)
 2) 进行比较的预期值(A)
 3) 拟写入的新值(B)
复制代码

CAS操做逻辑以下：ide

若是内存位置V的值等于预期的A值，则将该位置更新为新值B，不然不进行任何操做。

许多CAS的操做是自旋的：若是操做不成功，会一直重试，直到操做成功为止。

这里引出一个新的问题，既然CAS包含了Compare和Swap两个操做，它又如何保证原子性呢？

答案是：CAS是由CPU支持的原子操做，其原子性是在硬件层面进行保证的。

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

咱们知道，在Java中自增操做不是原子操做，它实际上包含三个独立的操做：

1) 读取i值；
2) 加1；
3) 将新值写回i
复制代码

所以，若是并发执行自增操做，可能致使计算结果的不许确。

在下面的代码示例中：value1没有进行任何线程安全方面的保护，value2使用了乐观锁(CAS)，value3使用了悲观锁(synchronized)。

运行程序，使用1000个线程同时对value一、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();
            }
            //查看活跃线程 ,因守护线程的缘由[基于工具问题windows:idea run 启动用 >2,debug 用>1] 
            while (Thread.activeCount() > 2) {
                //Thread.currentThread().getThreadGroup().list();
                Thread.yield();//让出cpu
            }

            //打印结果  
            Thread.sleep(1000);
            System.out.println("线程不安全：" + value1);
            System.out.println("乐观锁(AtomicInteger)：" + value2);
            System.out.println("悲观锁(synchronized)：" + value3);
        }
    }
复制代码

上面的代码中:

1)首先来介绍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;  
    }  
}  
}
复制代码

源码分析说明以下：

  1. getAndIncrement()实现的自增操做是自旋CAS操做：在循环中进行compareAndSet，若是执行成功则退出，不然一直执行。

  2. 其中compareAndSet是CAS操做的核心，它是利用Unsafe对象实现的。

  3. Unsafe又是何许人也呢？

Unsafe是用来帮助Java访问操做系统底层资源的类（如能够分配内存、释放内存,在netty中大量用到它,属于C++层面的native方法,咱们通常使用反射获取,哈哈~），经过Unsafe，Java具备了底层操做能力，能够提高运行效率；

强大的底层资源操做能力也带来了安全隐患(类的名字Unsafe也在提醒咱们这一点)，所以正常状况下用户没法使用。

AtomicInteger在这里使用了Unsafe提供的CAS功能。

  1. valueOffset能够理解为value在内存中的偏移量，对应了CAS三个操做数(V/A/B)中的V；偏移量的得到也是经过Unsafe实现的。

  2. value域的volatile修饰符：Java并发编程要保证线程安全，须要保证原子性、可视性和有序性；

CAS操做能够保证原子性，而volatile能够保证可视性和必定程度的有序性；

在AtomicInteger中，volatile和CAS一块儿保证了线程安全性。

关于volatile做用原理的说明涉及到Java内存模型(JMM)，这里不详细展开。

2) 说完了AtomicInteger，再说synchronized。

synchronized经过对代码块加锁来保证线程安全：在同一时刻，只能有一个线程能够执行代码块中的代码。

synchronized是一个重量级的操做，不只是由于加锁须要消耗额外的资源，还由于线程状态的切换会涉及操做系统核心态和用户态的转换；

不过随着JVM对锁进行的一系列优化(如自旋锁、轻量级锁、锁粗化等)，synchronized的性能表现已经愈来愈好。

二、版本号机制 除了CAS，版本号机制也能够用来实现乐观锁。

版本号机制的基本思路是在数据中增长一个字段version，表示该数据的版本号，每当数据被修改，版本号加1。

当某个线程查询数据时，将该数据的版本号一块儿查出来；

当该线程更新数据时，判断当前版本号与以前读取的版本号是否一致，若是一致才进行操做。

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

下面以“更新玩家金币数”为例（数据库为MySQL，其余数据库同理），看看悲观锁和版本号机制是如何应对并发问题的。

考虑这样一种场景：游戏系统须要更新玩家的金币数，更新后的金币数依赖于当前状态(如金币数、等级等)，所以更新前须要先查询玩家当前状态。

下面的实现方式，没有进行任何线程安全方面的保护。若是有其余线程在query和update之间更新了玩家的信息，会致使玩家金币数的不许确。

@Transactional
public void updateCoins(Integer playerId){
    //根据player_id查询玩家信息
    Player player = query("select coins, level from player where player_id = {0}", playerId);
    //根据玩家当前信息及其余信息，计算新的金币数
    Long newCoins = ……;
    //更新金币数
    update("update player set coins = {0} where player_id = {1}", newCoins, playerId);
}
复制代码

为了不这个问题，悲观锁经过加锁解决这个问题，代码以下所示。在查询玩家信息时，使用select …… for update进行查询；

该查询语句会为该玩家数据加上排它锁，直到事务提交或回滚时才会释放排它锁；

在此期间，若是其余线程试图更新该玩家信息或者执行select for update，会被阻塞(因此...若是你for update了,可是没有commit,那就一直锁着...锁住了青春~~~)。

@Transactional
public void updateCoins(Integer playerId){
    //根据player_id查询玩家信息（加排它锁）
    Player player = queryForUpdate("select coins, level from player where player_id = {0} for update", playerId);
    //根据玩家当前信息及其余信息，计算新的金币数
    Long newCoins = ……;
    //更新金币数
    update("update player set coins = {0} where player_id = {1}", newCoins, playerId);
}
复制代码

版本号机制则是另外一种思路，它为玩家信息增长一个字段：version。在初次查询玩家信息时，同时查询出version信息；

在执行update操做时，校验version是否发生了变化，若是version变化，则不进行更新。

@Transactional
public void updateCoins(Integer playerId){
    //根据player_id查询玩家信息，包含version信息
    Player player = query("select coins, level, version from player where player_id = {0}", playerId);
    //根据玩家当前信息及其余信息，计算新的金币数
    Long newCoins = ……;
    //更新金币数，条件中增长对version的校验
    update("update player set coins = {0} where player_id = {1} and version = {2}", newCoins, playerId, player.version);
}
复制代码

3、优缺点和适用场景

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

一、功能限制 与悲观锁相比，乐观锁适用的场景受到了更多的限制，不管是CAS仍是版本号机制。

例如，CAS只能保证单个变量操做的原子性，当涉及到多个变量时，CAS是无能为力的，而synchronized则能够经过对整个代码块加锁来处理。

再好比版本号机制，若是query的时候是针对表1，而update的时候是针对表2，也很难经过简单的版本号来实现乐观锁。

二、竞争激烈程度 若是悲观锁和乐观锁均可以使用，那么选择就要考虑竞争的激烈程度：

当竞争不激烈 (出现并发冲突的几率小)时，乐观锁更有优点，由于悲观锁会锁住代码块或数据，其余线程没法同时访问，影响并发，并且加锁和释放锁都须要消耗额外的资源。

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

4、面试官追问：乐观锁加锁吗？

笔者在面试时，曾遇到面试官如此追问。下面是我对这个问题的理解：

1.乐观锁自己是不加锁的，只是在更新时判断一下数据是否被其余线程更新了；AtomicInteger即是一个例子。

2.有时乐观锁可能与加锁操做合做，例如，在前述updateCoins()的例子中，MySQL在执行update时会加排它锁。

但这只是乐观锁与加锁操做合做的例子，不能改变“乐观锁自己不加锁”这一事实。

5、面试官追问：CAS有哪些缺点？

面试到这里，面试官可能已经中意你了。

不过面试官准备对你发起最后的进攻：你知道CAS这种实现方式有什么缺点吗？

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

一、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问题的。

二、高竞争下的开销问题 在并发冲突几率大的高竞争环境下，若是CAS一直失败，会一直重试，CPU开销较大。

针对这个问题的一个思路是引入退出机制，如重试次数超过必定阈值后失败退出。

固然，更重要的是避免在高竞争环境下使用乐观锁。

三、功能限制 CAS的功能是比较受限的，例如CAS只能保证单个变量（或者说单个内存值）操做的原子性，这意味着：

(1)原子性不必定能保证线程安全，例如在Java中须要与volatile配合来保证线程安全；

(2)当涉及到多个变量(内存值)时，CAS也无能为力。

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

6、总结

本文介绍了乐观锁和悲观锁的基本概念、实现方式(含实例)、适用场景，以及可能遇到的面试官追问，但愿可以对你面试有帮助。

联系我们 沪ICP备2021010478号-7