从 synchronized 到 CAS 和 AQS的超详细解析

素颜马尾好姑娘i 2024-03-27 10:47 26阅读 0赞

#### 文章目录 ####

*   *   *  一、Synchronized 关键字
         *  二、悲观锁和乐观锁
         *  三、公平锁和非公平锁
         *  四、可重入锁和不可重入锁
         *  五、CAS
         *   *  5.1、操作模型
             *  5.2、重试机制（循环 CAS）
             *  5.3、底层实现
             *  5.4、ABA 问题
         *  六、可重入锁 ReentrantLock
         *  七、AQS
         *   *  7.1、请求锁
             *  7.2、创建 Node 节点并加入链表
             *  7.3、挂起等待
             *  7.4、释放锁
         *  八、可重入读写锁 ReentrantReadWriteLock
         *   *  读写锁机制
             *  实现原理

--------------------

#### 一、Synchronized 关键字 ####

Synchronized 是一种独占锁。在修饰静态方法时，锁的是类对象，如 Object.class。修饰非静态方法时，锁的是对象，即 this。修饰方法块时，锁的是括号里的对象。 每个对象有一个锁和一个等待队列，锁只能被一个线程持有，其他需要锁的线程需要阻塞等待。锁被释放后，对象会从队列中取出一个并唤醒，唤醒哪个线程是不确定的，不保证公平性。

#### 二、悲观锁和乐观锁 ####

**悲观锁**  
总是假设最坏的情况，每次去拿数据的时候都认为别人会修改，所以每次在拿数据的时候都会上锁，这样别人想拿这个数据就会阻塞直到它拿到锁（共享资源每次只给一个线程使用，其它线程阻塞，用完后再把资源转让给其它线程）。传统的关系型数据库里边就用到了很多这种锁机制，比如行锁，表锁等，读锁，写锁等，都是在做操作之前先上锁。Java中synchronized和ReentrantLock等独占锁就是悲观锁思想的实现。

**乐观锁**  
总是假设最好的情况，每次去拿数据的时候都认为别人不会修改，所以不会上锁，但是在更新的时候会判断一下在此期间别人有没有去更新这个数据，可以使用版本号机制和CAS算法实现。乐观锁适用于多读的应用类型，这样可以提高吞吐量，像数据库提供的类似于write\_condition机制，其实都是提供的乐观锁。在Java中java.util.concurrent.atomic包下面的原子变量类就是使用了乐观锁的一种实现方式CAS实现的。

**两种锁的使用场景**  
从上面对两种锁的介绍，我们知道两种锁各有优缺点，不可认为一种好于另一种，像乐观锁适用于写比较少的情况下（多读场景），即冲突真的很少发生的时候，这样可以省去了锁的开销，加大了系统的整个吞吐量。但如果是多写的情况，一般会经常产生冲突，这就会导致上层应用会不断的进行retry，这样反倒是降低了性能，所以一般多写的场景下用悲观锁就比较合适。

#### 三、公平锁和非公平锁 ####

**公平锁**：多个线程按照申请锁的顺序去获得锁，线程会直接进入队列去排队，永远都是队列的第一位才能得到锁。

*  优点：所有的线程都能得到资源，不会饿死在队列中。
 *  缺点：吞吐量会下降很多，队列里面除了第一个线程，其他的线程都会阻塞，cpu唤醒阻塞线程的开销会很大。

**非公平锁**：多个线程去获取锁的时候，会直接去尝试获取，获取不到，再去进入等待队列，如果能获取到，就直接获取到锁，值得注意的是，在 AQS 的实现中，一旦线程进入排队队列，即使是非公平锁，线程也得乖乖排队。

*  优点：可以减少CPU唤醒线程的开销，整体的吞吐效率会高点，CPU也不必取唤醒所有线程，会减少唤起线程的数量。
 *  缺点：你们可能也发现了，这样可能导致队列中间的线程一直获取不到锁或者长时间获取不到锁，导致饿死。

#### 四、可重入锁和不可重入锁 ####

**不可重入锁**：只判断这个锁有没有被锁上，只要被锁上申请锁的线程都会被要求等待。实现简单

**可重入锁**：不仅判断锁有没有被锁上，还会判断锁是谁锁上的，当就是自己锁上的时候，那么他依旧可以再次访问临界资源，并把加锁次数加1；释放锁的时候，锁次数减1。

#### 五、CAS ####

##### 5.1、操作模型 #####

![image-20230130184011972][]

CAS 是 compare and swap 的简写，即比较并交换。它是指一种操作机制，而不是某个具体的类或方法。在 Java 平台上对这种操作进行了包装。在 Unsafe 类中，调用代码如下：

unsafe.compareAndSwapInt(this, valueOffset, expect, update);

它需要三个参数，分别是内存位置 V，旧的预期值 A 和新的值 B。操作时，先从内存位置读取到值，然后和预期值A比较。如果相等，则将此内存位置的值改为新值 B，返回 true。如果不相等，说明和其他线程冲突了，则不做任何改变，返回 false。

这种机制在不阻塞其他线程的情况下避免了并发冲突，比独占锁的性能高很多。 CAS 在 Java 的原子类和并发包中有大量使用。

##### 5.2、重试机制（循环 CAS） #####

1、CAS 本身并未实现失败后的处理机制，它只负责返回成功或失败的布尔值，后续由调用者自行处理。最常用的处理方式是重试而已。

2、实际上失败的时候，原值已经被修改，如果不更改期望值，再怎么比较都会失败。而新值同样需要修改。

所以正确的方法是，使用一个死循环进行 CAS 操作，成功了就结束循环返回，失败了就重新从内存读取值和计算新值，再调用 CAS。

##### 5.3、底层实现 #####

CAS 主要分三步，读取-比较-修改。其中比较是在检测是否有冲突，如果检测到没有冲突后，其他线程还能修改这个值，那么 CAS 还是无法保证正确性。所以最关键的是要保证比较-修改这两步操作的原子性。

CAS 底层是靠调用 CPU 指令集的 cmpxchg 完成的，它是 x86 和 Intel 架构中的 compare and exchange 指令。在多核的情况下，这个指令也不能保证原子性，需要在前面加上 lock 指令。lock 指令可以保证一个 CPU 核心在操作期间独占一片内存区域。那么 这又是如何实现的呢？

在处理器中，一般有两种方式来实现上述效果：总线锁和缓存锁。在多核处理器的结构中，CPU 核心并不能直接访问内存，而是统一通过一条总线访问。总线锁就是锁住这条总线，使其他核心无法访问内存。这种方式代价太大了，会导致其他核心停止工作。而缓存锁并不锁定总线，只是锁定某部分内存区域。当一个 CPU 核心将内存区域的数据读取到自己的缓存区后，它会锁定缓存对应的内存区域。锁住期间，其他核心无法操作这块内存区域。

CAS 就是通过这种方式实现比较和交换操作的原子性的。**值得注意的是， CAS 只是保证了操作的原子性，并不保证变量的可见性，因此变量需要加上 volatile 关键字。**

![image-20230130185255141][]

##### 5.4、ABA 问题 #####

上面提到，CAS 保证了比较和交换的原子性。但是从读取到开始比较这段期间，其他核心仍然是可以修改这个值的。如果核心将 A 修改为 B，CAS 可以判断出来。但是如果核心将 A 修改为 B 再修改回 A。那么 CAS 会认为这个值并没有被改变，从而继续操作。这是和实际情况不符的。解决方案是加一个版本号。

#### 六、可重入锁 ReentrantLock ####

ReentrantLock 使用代码实现了和 synchronized 一样的语义，包括可重入，保证内存可见性和解决竞态条件问题等。相比 synchronized，它还有如下好处：

*  支持以非阻塞方式获取锁
 *  可以响应中断
 *  可以限时
 *  支持了公平锁和非公平锁

基本用法如下：

public class Counter {
        
        private final Lock lock = new ReentrantLock();
        private volatile int count;
    
        public void incr() {
        
            lock.lock();
            try {
        
                count++;
            } finally {
        
                lock.unlock();
            }
        }
    
        public int getCount() {
        
            return count;
        }
    }

ReentrantLock 内部有两个内部类，分别是 FairSync 和 NoFairSync，对应公平锁和非公平锁。他们都继承自 Sync。Sync 又继承自AQS。

#### 七、AQS ####

![image-20230130184126542][]

AQS 全称 AbstractQueuedSynchronizer。AQS 中有两个重要的成员：

*  成员变量 state。用于表示锁现在的状态，用 volatile 修饰，保证内存一致性。同时所用对 state 的操作都是使用 CAS 进行的。state 为0表示没有任何线程持有这个锁，线程持有该锁后将 state 加1，释放时减1。多次持有释放则多次加减。
 *  还有一个双向链表，链表除了头结点外，每一个节点都记录了线程的信息，代表一个等待线程。这是一个 FIFO 的链表。

下面以 ReentrantLock 非公平锁的代码看看 AQS 的原理。

##### 7.1、请求锁 #####

请求锁时有三种可能：

1.  如果没有线程持有锁，则请求成功，当前线程直接获取到锁。
2.  如果当前线程已经持有锁，则使用 CAS 将 state 值加1，表示自己再次申请了锁，释放锁时减1。这就是可重入性的实现。
3.  如果由其他线程持有锁，那么将自己添加进等待队列。

##### 7.2、创建 Node 节点并加入链表 #####

如果没竞争到锁，这时候就要进入等待队列。队列是默认有一个 head 节点的，并且不包含线程信息。上面情况3中，addWaiter 会创建一个 Node，并添加到链表的末尾，Node 中持有当前线程的引用。同时还有一个成员变量 waitStatus，表示线程的等待状态，初始值为0。我们还需要关注两个值：

*  CANCELLED，值为1，表示取消状态，就是说我不要这个锁了，请你把我移出去。
 *  SINGAL，值为-1，表示下一个节点正在挂起等待，注意是下一个节点，不是当前节点。

##### 7.3、挂起等待 #####

*  如果此节点的上一个节点是头部节点，则再次尝试获取锁，获取到了就移除并返回。获取不到就进入下一步；
 *  判断前一个节点的 waitStatus，如果是 SINGAL，则返回 true，并调用 LockSupport.park() 将线程挂起；
 *  如果是 CANCELLED，则将前一个节点移除；
 *  如果是其他值，则将前一个节点的 waitStatus 标记为 SINGAL，进入下一次循环。

##### 7.4、释放锁 #####

*  调用 tryRelease，此方法由子类实现。实现非常简单，如果当前线程是持有锁的线程，就将 state 减1。减完后如果 state 大于0，表示当前线程仍然持有锁，返回 false。如果等于0，表示已经没有线程持有锁，返回 true，进入下一步；
 *  如果头部节点的 waitStatus 不等于0，则调用LockSupport.unpark()唤醒其下一个节点。头部节点的下一个节点就是等待队列中的第一个线程，这反映了 AQS 先进先出的特点。另外，即使是非公平锁，进入队列之后，还是得按顺序来。

#### 八、可重入读写锁 ReentrantReadWriteLock ####

##### 读写锁机制 #####

理解 ReentrantLock 和 AQS 之后，再来理解读写锁就很简单了。读写锁有一个读锁和一个写锁，分别对应读操作和锁操作。锁的特性如下：

*  只有一个线程可以获取到写锁。在获取写锁时，只有没有任何线程持有任何锁才能获取成功；
 *  如果有线程正持有写锁，其他任何线程都获取不到任何锁；
 *  没有线程持有写锁时，可以有多个线程获取到读锁。

上面锁的特点保证了可以并发读取，这大大提高了效率，在实际开发中非常有用。那么在具体是如何实现的呢？

##### 实现原理 #####

读写锁虽然有两个锁，但实际上只有一个等待队列。

*  获取写锁时，要保证没有任何线程持有锁；
 *  写锁释放后，会唤醒队列第一个线程，可能是读锁和写锁；
 *  获取读锁时，先判断写锁有没有被持有，没有就可以获取成功；
 *  获取读锁成功后，会将队列中等待读锁的线程依次唤醒，知道遇到等待写锁的线程位置；
 *  释放读锁时，要检查读锁数，如果为0，则唤醒队列中的下一个线程，否则不进行操作。

**参考文章**：[从 synchronized 到 CAS 和 AQS - 彻底弄懂 Java 各种并发锁][synchronized _ CAS _ AQS - _ Java]

[image-20230130184011972]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/27/03721288f4614b1c9d2c8a011e6b83fa.png
[image-20230130185255141]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/27/f4599e1009c9421eac44a11838b01380.png
[image-20230130184126542]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/27/0ac795b2f4334e9a9a4c980653f68e11.png
[synchronized _ CAS _ AQS - _ Java]: https://juejin.cn/post/6844903759047294983