锁介绍

在计算机科学中，锁（lock）是一种同步机制，用于在有多线程环境中强制对资源的访问限制，锁要解决的问题是 线程安全问题

所谓线程安全，主要体现在三方面：原子性、可见性和有序性

1. 原子性：提供互斥访问，同一时刻只能有一个线程对数据进行操作。（ Java 的实现方法：synchronized、lock）
2. 可见性：一个线程对主内存的修改可以及时被其他线程看到。（ Java 的实现方法：volatile）
3. 有序性：一个线程观察其他线程的指令执行顺序，由于在 JMM 中允许编译器和处理器对指令重排序，因此该观察结果一般杂乱无序。（ Java 的实现方法：volatile）

锁的种类

以下将从实现功能、性能和线程安全、以及锁的状态三个角度来分，锁一共可分为以下几种类型

• 功能层面：共享锁、排他锁、读写锁

• 性能线程安全：

  • 乐观锁、悲观锁
  • 偏向锁、轻量级锁（自旋锁）、重量级锁（排他锁）
  • 公平锁、非公平锁

• 锁的状态：死锁、活锁

实现功能

若从功能角度来看，锁可以分为三类：共享锁、排他锁、读写锁

• 共享锁：也叫读锁（例如 ReadWriteLock ），读锁的特点是在同一时刻允许多个线程抢占到锁。

• 排它锁：也叫写锁（例如 ReentrantLock 、 synchronized），写锁的特点是在同一时刻只允许一个线程抢占到锁。

• 读写锁：例如 ReentrantReadWriteLock，其中低 16 位代表写锁，高 16 位代表读锁

  • 该读写锁 ReentrantReadWriteLock 提供了一个读锁，支持多个线程共享同一把锁。
  • 它也提供了一把写锁，是排他锁，和其他读锁或者写锁互斥，表明只有一个线程能持有锁资源。

性能和线程安全

乐观锁、悲观锁

• 乐观锁
  • 每次去读取数据时，都认为其他人不会修改该数据，因此不会加锁；修改数据，提交更新时候会判断在此期间是否有他人去更新此数据
  • 实现方式：使用版本号机制、或者 CAS 算法
  • 适合读多写少的场景，需要非常高的响应速度
• 悲观锁
  • 总是假设最坏的情况，每次去 拿（读取/修改） 数据的时候都认为别人会修改，所以每次在拿数据的时候都会上锁
  • 适合读少写多的场景

偏向锁、轻量级锁、重量级锁

• 偏向锁：

  • 定义：可以让同一线程一直拥有同一个锁，直到出现竞争，才去释放锁
  • 场景：应用于同步代码块在大多数情况下只有同一个线程访问
  • 举例：所谓偏向锁就是当线程 1 进入锁的时候如果当前不存在竞争，那么它就会把这个锁偏向线程 1，线程 1 下次再进入的时候，就不再需要竞争锁

• 轻量级锁（自旋锁）

  • 定义：轻量级锁即通过自旋方式不断尝试获取锁，而不是阻塞。当偏向锁被其他线程访问后，就会升级为轻量级锁。常见的轻量级锁即自旋锁
  • 场景：前提是线程在临界区的操作非常快，所以它会非常快速地释放锁

• 重量级锁（排他锁）

  • 定义：有一个线程获取锁之后，其余所有等待获取该锁的线程都会处于阻塞状态
  • 场景：有大量的线程参与锁的竞争，冲突性很高

公平锁、非公平锁

• 公平锁：每个线程获取锁的顺序是按照线程访问锁的先后顺序获取的；
• 非公平锁：每个线程获取锁的顺序是随机的，并不会遵循先来后到的规则，所有线程会竞争获取锁。

默认情况下锁都是非公平的，比如 Synchronized(只能为非公平锁)、Reentrantlock(在创建 Reentrantlock 时可以手动指定成公平锁)

因为非公平锁的性能要比公平锁的性能更好，非公平锁意味着减少了锁的等待，减少了线程的阻塞和唤醒。

锁的状态

按照锁的状态分，可以分为死锁和活锁

死锁

1. 定义：指两个或两个以上的线程在执行过程中，因争夺资源造成的一种互相等待的现象。当一个线程永久地持有一把锁后，其他线程将永久等待下去

2. 四个条件：

   1. 互斥性：即线程占用的锁是互斥锁，不能被其他为占用的线程访问
   2. 不剥夺：即线程已经获得锁，在未主动释放之前，不会被其他线程剥夺
   3. 请求和保持：即有锁 S1,S2，线程一持有了 S1，又发起了对 S2 的持有请求。而同时有线程二持有了 S2，又发起了对 S1 的持有请求。
   4. 环路等待：即死锁发生时，必然有一个环形链。如{p0,p1,p2,....pn}。p0 等待 p1 释放资源，p1 等待 p2 释放资源，p2 等待 p3 释放资源，.... pn 等待 p0 释放资源

3. 解决方式：

   1. jstack 定位死锁：https://www.cnblogs.com/chenpi/p/5377445.html
   2. 线上环境死锁，查看堆栈信息：使用 jps 和 jstack 命令分别查看 JVM 中运行的进程状态信息、以及 java 进程内线程的堆栈信息

4. 死锁避免：

   1. 避免相反的获取锁的顺序
   2. 设置超时时间(lock 类的 tryLock)
   3. 多使用并发类而不是自己设计锁

活锁

1. 定义：活锁即线程并没有阻塞，也始终在运行，但是程序却得不到进展，因为线程始终重复做同样的事。本质原因是重试机制一样，始终互相谦让
2. 案例：例如消息队列，若消息队列第一个一直消费失败，则会不断进行重试。而非第一个消息则会一直等待第一个消息被消费，造成了整个队列的罢工
3. 解决方案：

• 增加随机因素
• 增加重试机制

乐观锁和悲观锁

悲观锁

• 定义：认为共享资源每次被访问的时候，都会被其他事务修改，所以每次在获取资源操作的时候都会上锁。也就是说，共享资源每次只给一个线程使用，其它线程阻塞，用完后再把资源转让给其它线程
• 举例：Java 的 synchronized、ReentrantLock
• 问题：高并发的场景下，激烈的锁竞争会造成线程阻塞，大量阻塞线程会导致系统的上下文切换，增加系统的性能开销。并且，悲观锁还可能会存在死锁问题，影响代码的正常运行

乐观锁

• 定义：认为共享资源每次被访问的时候，其他事务不会去修改该资源，访问不会加锁。在提交修改的时候去验证对应的资源是否被其它线程修改
• 举例：像 Java 中java.util.concurrent.atomic包下面的原子变量类（比如AtomicInteger、LongAdder）就是使用了乐观锁的一种实现方式：CAS 实现的
• 问题：高并发的场景下，乐观锁不存在锁竞争造成线程阻塞，也不会有死锁的问题，在性能上往往会更胜一筹。但是，如果冲突频繁发生（写占比非常多的情况），会频繁失败和重试（悲观锁的开销是固定的），这样同样会非常影响性能，导致 CPU 飙升

版本号机制

实现方式：一般是在数据表中加上一个数据版本号 version 字段，表示数据被修改的次数。当数据被修改时，version 值会加一。

当线程 A 要更新数据值时，在读取数据的同时也会读取 version 值，在提交更新时，若刚才读取到的 version 值为当前数据库中的 version 值相等时才更新，否则重试更新操作，直到更新成功

CAS 算法

CAS 的全称是 Compare And Swap（比较与交换） ，用于实现乐观锁，被广泛应用于各大框架中。CAS 的思想很简单，就是用一个预期值和要更新的变量值进行比较，两值相等才会进行更新。

CAS 是一个原子操作，底层依赖于一条 CPU 的原子指令。

原子操作 即最小不可拆分的操作，也就是说操作一旦开始，就不能被打断，直到操作完成。

CAS 涉及到的三个操作数：

• V：要更新的变量值(Var)
• E：预期值(Expected)
• N：拟写入的新值(New)

当且仅当 V 的值等于 E 时，CAS 通过原子方式用新值 N 来更新 V 的值。如果不等，说明已经有其它线程更新了 V，则当前线程放弃更新。

• 举例：

  • 线程 A 要修改变量 i 的值为 6，i 原值为 1（V = 原变量值（现在不一定为 1），E=1，N=6，假设不存在 ABA 问题）
  • V 与 E 进行比较，如果相等， 则说明没被其他线程修改，可以被设置为 6 。
  • V 与 E 进行比较，如果不相等，则说明被其他线程修改，当前线程放弃更新，CAS 操作失败。

• 当多个线程同时使用 CAS 操作一个变量时，只有一个会胜出，并成功更新，其余均会失败，但失败的线程并不会被挂起，仅是被告知失败，并且允许再次尝试，当然也允许失败的线程放弃操作。

• Java 语言并没有直接实现 CAS，CAS 相关的实现是通过 C++ 内联汇编的形式实现的（JNI 调用）。因此， CAS 的具体实现和操作系统以及 CPU 都有关系。

• sun.misc包下的Unsafe类提供了compareAndSwapObject、compareAndSwapInt、compareAndSwapLong方法来实现的对Object、int、long类型的 CAS 操作

  /**
    *  CAS
    * @param o         包含要修改field的对象
    * @param offset    对象中某field的偏移量
    * @param expected  期望值
    * @param update    更新值
    * @return          true | false
    */
  public final native boolean compareAndSwapObject(Object o, long offset,  Object expected, Object update);
  
  public final native boolean compareAndSwapInt(Object o, long offset, int expected,int update);
  
  public final native boolean compareAndSwapLong(Object o, long offset, long expected, long update);

CAS 底层：依赖一个 Unsafe 类来直接调用操作系统底层的 CAS 指令

如下，ReentrantLock 的一段 CAS 代码：this 表示当前值，从数据库读取的值；expect 表示期待的值；update 表示修改后的值

protected final boolean compareAndSetState(int expect,int update){
    return STATE.compareAndSet(this,expect,update);
}

ABA 问题

问题描述：如果一个变量 V 初次读取的时候是 A 值，并且在准备赋值的时候检查到它仍然是 A 值，那我们就能说明它的值没有被其他线程修改过了吗？很明显是不能的，因为在这段时间它的值可能被改为其他值，然后又改回 A，那 CAS 操作就会误认为它从来没有被修改过。这个问题被称为 CAS 操作的 "ABA"问题。

解决问题

ABA 问题的解决思路是在变量前面追加上版本号或者时间戳

JDK 1.5 以后的 AtomicStampedReference 类就是用来解决 ABA 问题的，其中的 compareAndSet() 方法就是首先检查当前引用是否等于预期引用，并且当前标志是否等于预期标志，如果全部相等，则以原子方式将该引用和该标志的值设置为给定的更新值

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 经常会用到自旋操作来进行重试，也就是不成功就一直循环执行直到成功。如果长时间不成功，会给 CPU 带来非常大的执行开销。

如果 JVM 能支持处理器提供的 pause 指令那么效率会有一定的提升，pause 指令有两个作用：

1. 可以延迟流水线执行指令，使 CPU 不会消耗过多的执行资源，延迟的时间取决于具体实现的版本，在一些处理器上延迟时间是零。
2. 可以避免在退出循环的时候因内存顺序冲突而引起 CPU 流水线被清空，从而提高 CPU 的执行效率

小结

1. 悲观锁适用读少写多的场景，乐观锁适用于读多写少的场景
2. 乐观锁一般会使用版本号机制或 CAS 算法实现，CAS 算法相对来说更多一些
3. CAS 的全称是 Compare And Swap（比较与交换） ，用于实现乐观锁，被广泛应用于各大框架中。CAS 的思想很简单，就是用一个预期值和要更新的变量值进行比较，两值相等才会进行更新。
4. 乐观锁的问题：ABA 问题、循环时间长开销大、只能保证一个共享变量的原子操作。

锁消除/锁膨胀

在 JDK 中，还引入了锁消除和锁膨胀，这是编译器层面的优化，主要优化加锁的性能。

• 锁消除：代码本身可能就没有线程安全问题，但是你又加了锁，然后 ivm 编译的时候发现这个地方加了锁，导致无效竞争，那么它就会把这个锁消除掉
• 锁膨胀：因为控制的锁粒度太小，导致频繁加锁和释放锁，所以它就会把锁的范围扩大

版权所有

版权归属：haipeng-lin

许可证：署名 4.0 国际 (CC-BY-4.0)