Java多线程进阶：锁策略、CAS和Synchronized的精髓解析与优化

﹏ヽ暗。殇╰゛Y 2023-09-27 17:17 34阅读 0赞

**目录**

1. 锁策略

乐观锁 和 悲观锁

读写锁

重量级锁 和 轻量级锁

自旋锁 和 挂起等待锁

公平锁 和 非公平锁

可重入锁 和 不可重入锁

CAS

什么是CAS？

CAS 是怎么实现的

CAS 有哪些应用？

CAS 的 ABA 问题

ABA 问题引来的 BUG

Synchronized 原理

Synchronized的特点

Synchronized的加锁工作过程

其他的一些优化操作

锁消除

锁粗化

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

## 1. 锁策略 ##

### **乐观锁 和 悲观锁** ###

乐观锁：

**假设数据一般情况下不会产生并发冲突，所以在数据进行提交更新的时候，才会正式对数据是否产生并 发冲突进行检测，如果发现并发冲突了，则让返回用户错误的信息，让用户决定如何去做**

悲观锁:

**总是假设最坏的情况，每次去拿数据的时候都认为别人会修改，所以每次在拿数据的时候都会上锁，这 样别人想拿这个数据就会阻塞直到它拿到锁**

> Synchronized初始使用乐观锁策略，当发现锁竞争比较频繁的时候，就会自动切换成悲观锁策略

乐观锁的一个重要功能就是要检测出数据是否发生访问冲突. 我们可以引入一个 "**版本号**" 来解决

假设我们需要多线程修改 "用户账户余额"，设当前余额为 100，引入一个版本号 version，初始值为 1，**并且我们规定 "提交版本必须大于记录 当前版本才能执行更新余额"**

（1） 线程 A 此时准备将其读出（ version=1，balance=100 ），线程 B 也读入此信息（ version=1，balance=100 ）

![1e119f11365943ada7dbc9e811768778.png][]

（2） 线程 A 操作的过程中并从其帐户余额中扣除 50（ 100-50 ），线程 B 从其帐户余额中扣除 20 （ 100-20 ）；

![6df14c2e836a44579a85e33e0c08cb37.png][]

（3）线程 A 完成修改工作，将数据版本号加1（ version=2 ），连同帐户扣除后余额（ balance=50 ），写回到内存中

![e3d6797a583a4dfaa941d00ff6bdb2c6.png][]

（4）线程 B 完成了操作，也将版本号加1（ version=2 ）试图向内存中提交数据（ balance=80 ），但此时比对版本发现，操作员 B 提交的数据版本号为2，数据库记录的当前版本也为2，不满足 “**提交版本必须大于记录当前版本才能执行更新**“ 的乐观锁策略。就认为这次操作失败

![95dc33fa0ded48a7951d375242cd5de7.png][]

### 读写锁 ###

> 多线程之间，数据的读取方之间不会产生线程安全问题，但数据的写入方互相之间以及和读者之间都需要进行互斥。如果两种场景下都用同一个锁，就会产生极大的性能损耗。

所以读写锁因此而产生，读写锁在执行加锁操作时需要额外表明读写意图，复数读者之间并不互斥，而写者则要求与任何人互斥，读写锁特别适合于 "频繁读, 不频繁写" 的场景中

> 一个线程对于数据的访问, 主要存在两种操作：**读数据** 和 **写数据**
> 
> 1. 两个线程都只是读一个数据，此时并没有线程安全问题，直接并发的读取即可
> 
> 2. 两个线程都要写一个数据，有线程安全问题
> 
> 3. 一个线程读另外一个线程写，也有线程安全问题

读写锁就是把读操作和写操作区分对待；Java 标准库提供了 ReentrantReadWriteLock 类，实现了读写锁

1. ReentrantReadWriteLock.ReadLock 类表示一个读锁，这个对象提供了 lock / unlock 方法进行 加锁解锁

2. ReentrantReadWriteLock.WriteLock 类表示一个写锁，这个对象也提供了 lock / unlock 方法进 行加锁解锁

注意：

1. 读加锁和读加锁之间，不互斥

2. 写加锁和写加锁之间，互斥

3. 读加锁和写加锁之间，互斥

> **只要是涉及到 "互斥"，就会产生线程的挂起等待，一旦线程挂起，再次被唤醒就不知道隔了多久了，如果想要效率高，应当减少"互斥"的机会**

**Synchronized 不是读写锁**

### 重量级锁 和 轻量级锁 ###

锁的核心特性 "原子性", 这样的机制追根溯源是 CPU 这样的硬件设备提供的

> **CPU 提供了 "原子操作指令"**
> 
> **操作系统基于 CPU 的原子指令, 实现了 mutex 互斥锁**
> 
> **JVM 基于操作系统提供的互斥锁, 实现了 synchronized 和 ReentrantLock 等关键字和类**

![5fd7bd1b9b5242cd907bacd24afe83b5.png][]

**重量级锁**：加锁机制重度依赖了 OS 提供了 mutex

1.大量的内核态用户态切换

2. 很容易引发线程的调度

> 这两个操作，成本比较高. 一旦涉及到用户态和内核态的切换，成本一下子就非常高了

**轻量级锁**：加锁机制尽可能不使用 mutex，而是尽量在用户态代码完成，实在搞不定了，再使用 mutex

1. 少量的内核态用户态切换

2. 不太容易引发线程调度

**什么是用户态和内核态？**

> 想象去银行办业务，在窗口外，自己办理业务，这是**用户态** 用户态的时间成本是比较可控的
> 
> 在窗口内，工作人员做，这是**内核态** 内核态的时间成本是不太可控的 如果办业务的时候反复和工作人员沟通，还需要重新排队，这时效率是很低的，而且时间成本也很高

**synchronized 开始是一个轻量级锁；如果锁冲突比较严重，就会变成重量级锁**

### 自旋锁 和 挂起等待锁 ###

**自旋锁：**

按之前的方式，线程在抢锁失败后进入阻塞状态，放弃 CPU，需要过很久才能再次被调度；但实际大部分情况，虽然当前抢锁失败，但过不了很久，锁就会被释放；没必要就放弃 CPU~ 这个时候就可以使用自旋锁来处理这样的问题

自旋锁伪代码:

while (抢锁(lock) == 失败) {
    
    }

如果获取锁失败，立即再尝试获取锁，无限循环，直到获取到锁为止，一旦锁被其他线程释放, 就能第一时间获取到锁

**自旋锁是一种典型的 轻量级锁 的实现方式**

**优点**: 没有放弃 CPU, 不涉及线程阻塞和调度，一旦锁被释放，就能第一时间获取到锁

**缺点**：如果锁被其他线程持有的时间比较久，那么就会持续的消耗 CPU 资源(而挂起等待的时候是 不消耗 CPU 的)

> **synchronized 中的轻量级锁策略大概率就是通过自旋锁的方式实现的**

**挂起等待锁：**

相当于自旋锁的反面例子，锁冲突时线程会离开CPU进行阻塞等待，等到锁被其他线程释放了再进入CPU运行

### 公平锁 和 非公平锁 ###

假设有三个线程，A，B，C，A先尝试获取锁，获取成功，B，C再尝试获取锁的时候就失败了，都阻塞等待，那么，当A释放锁的时候，会发生什么呢

**公平锁：**遵守 "先来后到"，B 比 C 先来的. 当 A 释放锁的之后, B 就能先于 C 获取到锁

**非公平锁：**不遵守 "先来后到"，B 和 C 都有可能获取到锁

> 这就好比一群男生追同一个女神，当女神和前任分手之后，先来追女神的男生做她的男朋友，这就是公平锁；如果是女神不按先后顺序挑一个自己看的顺眼的，就是非公平锁

操作系统内部的线程调度就可以视为是随机的，如果不做任何额外的限制，锁就是非公平锁. 如果要想实现公平锁，就需要依赖额外的数据结构，来记录线程们的先后顺序

**注意：synchronized 是非公平锁**

### 可重入锁 和 不可重入锁 ###

可重入锁的字面意思是“可以重新进入的锁”，即允许同一个线程多次获取同一把锁

**Java里只要以Reentrant开头命名的锁都是可重入锁，而且JDK提供的所有现成的Lock实现类，包括 synchronized关键字锁都是可重入的**

**而 Linux 系统提供的 mutex 是不可重入锁**

> "把自己锁死" ：一个线程没有释放锁, 然后又尝试再次加锁
> 
>     // 第一次加锁, 加锁成功
>     lock();
>     // 第二次加锁, 锁已经被占用, 阻塞等待. 
>     lock();
> 
> 按照之前对于锁的设定，第二次加锁的时候，就会阻塞等待；直到第一次的锁被释放，才能获取到第二个锁，但是释放第一个锁也是由该线程来完成，这个线程不释放锁，造成了死锁
> 
> 这样的锁称为 **不可重入锁**

**synchronized 是可重入锁**

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

## CAS ##

### 什么是CAS？ ###

CAS: 全称Compare and swap，字面意思:”比较并交换“，一个 CAS 涉及到以下操作

> 我们假设内存中的原数据V，旧的预期值A，需要修改的新值B
> 
> 1. 比较 A 与 V 是否相等。（比较）
> 
> 2. 如果比较相等，将 B 写入 V。（交换）
> 
> 3. 返回操作是否成功

CAS 伪代码

boolean CAS(address, expectValue, swapValue) {
     if (&address == expectedValue) {
       &address = swapValue;
            return true;
       }
        return false;
    }

上面的代码不是原子的，真实的 CAS 是一个原子的硬件指令完成的；这个伪代码只是帮助我们能辅助理解 CAS 的工作流程

> **当多个线程同时对某个资源进行CAS操作，只能有一个线程操作成功，但是并不会阻塞其他线程,其他线程只会收到操作失败的信号。**
> 
> **CAS 可以视为是一种乐观锁**

### CAS 是怎么实现的 ###

针对不同的操作系统，JVM 用到了不同的 CAS 实现原理，简单来讲：

> 1. java 的 CAS 利用的的是 unsafe 这个类提供的 CAS 操作
> 
> 2. unsafe 的 CAS 依赖了的是 jvm 针对不同的操作系统实现的 Atomic::cmpxchg
> 
> 3. Atomic::cmpxchg 的实现使用了汇编的 CAS 操作，并使用 cpu 硬件提供的 lock 机制保证其原子性

**实现CAS是因为硬件予以了支持，软件层面才能做到**

### CAS 有哪些应用？ ###

**实现原子类**

标准库中提供了 java.util.concurrent.atomic 包，里面的类都是基于这种方式来实现的

典型的就是 AtomicInteger 类，其中的 getAndIncrement 相当于 i++ 操作

AtomicInteger atomicInteger = new AtomicInteger(0);
    atomicInteger.getAndIncrement();// 这一步操作相当于 i++

伪代码：

class AtomicInteger {
        private int value;
        public int getAndIncrement() {
            int oldValue = value;
            while ( CAS(value, oldValue, oldValue+1) != true) {
                oldValue = value;
           }
            return oldValue;
       }
    }

假设两个线程同时调用 getAndIncrement

1. 两个线程都读取 value 的值到 oldValue 中 (oldValue 是一个局部变量，在栈上，每个线程有自己的栈)

![621009fc057045e8ac2264bbc7947689.png][]

2. 线程1 先执行 CAS 操作，由于 oldValue 和 value 的值相同，直接进行对 value 赋值

> CAS 是直接读写内存的，而不是操作寄存器
> 
> CAS 的读内存，比较，写内存操作是一条硬件指令，是原子的

![39de30cf148e492dadf3d16a2b461a5e.png][]

3. 线程2 再执行 CAS 操作，第一次 CAS 的时候发现 oldValue 和 value 不相等，不能进行赋值；因此需要进入循环：在循环里重新读取 value 的值赋给 oldValue

![f7b99d7a639843369c3df6f8d52b2f98.png][]

4. 线程2 接下来第二次执行 CAS，此时 oldValue 和 value 相同，于是直接执行赋值操作

![c762d3e6091a4b2da476b84f074da6d4.png][]

5. 线程1 和 线程2 返回各自的 oldValue 的值即可

通过形如上述代码就可以实现一个原子类，可以高效的完成多线程的自增操作

### CAS 的 ABA 问题 ###

ABA 的问题:

假设存在两个线程 t1 和 t2. 有一个共享变量 num，初始值为 A，接下来，线程 t1 想使用 CAS 把 num 值改成 Z，那么就需要

> 1. 先读取 num 的值, 记录到 oldNum 变量中
> 
> 2. 使用 CAS 判定当前 num 的值是否为 A, 如果为 A, 就修改成 Z

但是，在 t1 执行这两个操作之间，t2 线程可能把 num 的值从 A 改成了 B，又从 B 改成了 A

到这里，t1 线程无法区分当前这个变量始终是 A，还是经历了一个变化过程

![efda2378b7254fce842eb9a124162371.png][]

> 这就相当于，我们买一个手机，无法判定这个手机是刚出厂的新手机，还是别人用旧了，又翻新过的手机

### ABA 问题引来的 BUG ###

大部分的情况下，t2 线程这样的一个反复横跳改动，对于 t1 是否修改 num 是没有影响的. 但是有一些特殊情况，会使结果截然不同

举个栗子：

假设 张三 有 100 存款. 滑稽想从 ATM 取 50 块钱. 取款机创建了两个线程，并发的来执行 -50 操作. 我们期望一个线程执行 -50 成功，另一个线程 -50 失败. 如果使用 CAS 的方式来完成这个扣款过程就可能出现问题

正常情况下

> 1. 存款 100 线程1 获取到当前存款值为 100，期望更新为 50；线程2 获取到当前存款值为 100, 期 望更新为 50
> 
> 2. 线程1 执行扣款成功，存款被改成 50. 线程2 阻塞等待中
> 
> 3. 轮到线程2 执行了，发现当前存款为 50，和之前读到的 100 不相同，执行失败

异常情况下

> 1. 存款 100. 线程1 获取到当前存款值为 100，期望更新为 50；线程2 获取到当前存款值为 100，期望更新为 50
> 
> 2. 线程1 执行扣款成功，存款被改成 50. 线程2 阻塞等待中
> 
> 3. 在线程2 执行之前, 张三的朋友正好给张三转账 50，账户余额变成 100
> 
> 4. 轮到线程2 执行了，发现当前存款为 100，和之前读到的 100 相同，再次执行扣款操作

这个时候, 扣款操作被执行了两次~~

**解决方案**

给要修改的值，引入版本号. 在 CAS 比较数据当前值和旧值的同时，也要比较版本号是否符合预期

> 1. CAS 操作在读取旧值的同时, 也要读取版本号
> 
> 2. 修改的时候如果当前版本号和读到的版本号相同, 则修改数据, 并把版本号 + 1；如果当前版本号高于读到的版本号. 就操作失败(认为数据已经被修改过了)

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

## **Synchronized 原理** ##

### **Synchronized的特点** ###

结合上面的锁策略, 我们就可以总结出, Synchronized 具有以下特性：

> **1. 开始时是乐观锁，如果锁冲突频繁，就转换为悲观锁**
> 
> **2. 开始是轻量级锁实现，如果锁被持有的时间较长，就转换成重量级锁**
> 
> **3. 实现轻量级锁的时候大概率用到的自旋锁策略**
> 
> **4. 是一种不公平锁**
> 
> **5. 是一种可重入锁**
> 
> **6. 不是读写锁**

### **Synchronized的**加锁工作过程 ###

JVM 将 synchronized 锁分为 无锁、偏向锁、轻量级锁、重量级锁 状态。会根据情况，进行依次升级

![7571b2d7f43d492789230542f8e965a4.png][]

**1. 偏向锁**

第一个尝试加锁的线程, 优先进入偏向锁状态

**偏向锁不是真的 "加锁"**，只是给对象头中做一个 "偏向锁的标记"，记录这个锁属于哪个线程. 如果后续没有其他线程来竞争该锁，那么就不用进行加锁解锁之类的操作了（避免了加锁解锁的开销）

如果后续有其他线程来竞争该锁（刚才已经在锁对象中记录了当前锁属于哪个线程了，很容易识别 当前申请锁的线程是不是之前记录的线程），那就取消原来的偏向锁状态，进入一般的轻量级锁状态

**偏向锁本质上相当于 "延迟加锁" . 能不加锁就不加锁, 尽量来避免不必要的加锁开销**

**2. 轻量级锁**

随着其他线程进入竞争，偏向锁状态被消除，进入轻量级锁状态（自适应的自旋锁）

此处的轻量级锁就是通过 CAS 来实现

> 通过 CAS 检查并更新一块内存 （比如 null => 该线程引用）
> 
> 如果更新成功，则认为加锁成功
> 
> 如果更新失败，则认为锁被占用，继续自旋式的等待（并不放弃 CPU）

**自旋操作是一直让 CPU 空转，比较浪费 CPU 资源，因此此处的自旋不会一直持续进行，而是达到一定的时间/重试次数，就不再自旋了**

**3. 重量级锁**

如果竞争进一步激烈，自旋不能快速获取到锁状态，就会膨胀为**重量级锁**

> 此处的重量级锁就是指用到内核提供的 mutex

1. 执行加锁操作，先进入内核态

2. 在内核态判定当前锁是否已经被占用

3. 如果该锁没有占用，则加锁成功，并切换回用户态

4. 如果该锁被占用，则加锁失败. 此时线程进入锁的等待队列，挂起. 等待被操作系统唤醒

5. 过了很久，当这个锁被其他线程释放了，操作系统也想起了这个挂起的线程，于是唤醒这个线程，尝试重新获取锁

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

## 其他的一些优化操作 ##

### 锁消除 ###

编译器+JVM 判断锁是否可消除. 如果可以，就直接消除

**什么是锁消除？**

有些应用程序的代码中, 用到了 synchronized, 但其实没有在多线程环境下. (例如 StringBuffer)

StringBuffer sb = new StringBuffer();
    sb.append("a");
    sb.append("b");
    sb.append("c");
    sb.append("d");

此时每个 append 的调用都会涉及加锁和解锁. 但如果只是在单线程中执行这个代码，那么这些加 锁解锁操作是没有必要的，白白浪费了一些资源开销

### 锁粗化 ###

一段逻辑中如果出现多次加锁解锁, 编译器 + JVM 会自动进行锁的粗化

> 锁的粒度: 粗和细
> 
> ![f0ff246668d1426aa6a93e2e4affe39b.png][]
> 
> 实际开发过程中，使用细粒度锁，是期望释放锁的时候其他线程能使用锁
> 
> 但是实际上可能并没有其他线程来抢占这个锁. 这种情况 JVM 就会自动把锁粗化，避免频繁申请释放锁

谢谢大家的观看，喜欢就关注我吧，下节我会给大家带来一些关于多线程的面试题~~

[1e119f11365943ada7dbc9e811768778.png]: https://img-blog.csdnimg.cn/1e119f11365943ada7dbc9e811768778.png
[6df14c2e836a44579a85e33e0c08cb37.png]: https://img-blog.csdnimg.cn/6df14c2e836a44579a85e33e0c08cb37.png
[e3d6797a583a4dfaa941d00ff6bdb2c6.png]: https://img-blog.csdnimg.cn/e3d6797a583a4dfaa941d00ff6bdb2c6.png
[95dc33fa0ded48a7951d375242cd5de7.png]: https://img-blog.csdnimg.cn/95dc33fa0ded48a7951d375242cd5de7.png
[5fd7bd1b9b5242cd907bacd24afe83b5.png]: https://img-blog.csdnimg.cn/5fd7bd1b9b5242cd907bacd24afe83b5.png
[621009fc057045e8ac2264bbc7947689.png]: https://img-blog.csdnimg.cn/621009fc057045e8ac2264bbc7947689.png
[39de30cf148e492dadf3d16a2b461a5e.png]: https://img-blog.csdnimg.cn/39de30cf148e492dadf3d16a2b461a5e.png
[f7b99d7a639843369c3df6f8d52b2f98.png]: https://img-blog.csdnimg.cn/f7b99d7a639843369c3df6f8d52b2f98.png
[c762d3e6091a4b2da476b84f074da6d4.png]: https://img-blog.csdnimg.cn/c762d3e6091a4b2da476b84f074da6d4.png
[efda2378b7254fce842eb9a124162371.png]: https://img-blog.csdnimg.cn/efda2378b7254fce842eb9a124162371.png
[7571b2d7f43d492789230542f8e965a4.png]: https://img-blog.csdnimg.cn/7571b2d7f43d492789230542f8e965a4.png
[f0ff246668d1426aa6a93e2e4affe39b.png]: https://img-blog.csdnimg.cn/f0ff246668d1426aa6a93e2e4affe39b.png