[多线程进阶]CAS与Synchronized基本原理

川长思鸟来 2024-03-27 13:36 85阅读 0赞

## ![d0cd85e69a244a22a8c2a97f14682312.gif][] ##

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

> ![c4304daa3a1846adadc000eea43efbf4.png][]专栏简介: JavaEE从入门到进阶
> 
> ![1254c5b119a44cf0ae350489fb7736ad.png][]题目来源: leetcode,牛客,剑指offer.
> 
> ![4366a93aaa3142b5a0f16c7a2200339b.png][]创作目标: 记录学习JavaEE学习历程
> 
> ![52a3437a932f4621b25533c330f7c6cb.png][]希望在提升自己的同时,帮助他人,,与大家一起共同进步,互相成长.
> 
> ![14aa2f0648ae44a299b8f9832af57d2c.png][]学历代表过去,能力代表现在,学习能力代表未来!

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

## 目录: ##

1.CAS

1.1 什么是CAS?

1.2 CAS伪代码

1.3 CAS 是怎么实现的

1.4 CAS 的应用场景

1) 实现原子类

2) 实现自旋锁(伪代码)

1.5 CAS 的 ABA 问题

1.6 ABA问题引发的 BUG

1.7 相关面试题

2. Synchronized 基本原理

2.1 基本特点

2.2 加锁过程

2.3 其他的优化操作

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

## 1.CAS ##

### **1.1 什么是CAS?** ###

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

> 假设内存中原数据 V , A B 分别为寄存器中 , 旧的预期值和需要修改的新值.
> 
>  *  1. 比较 A 与 V 是否相等.(比较)
>  *  2. 如果比较相等 , 将 B 写入 V. (交换)
>  *  3. 返回操作是否成功.

![0a84a36dd05c440e837fc8d63dd5ec07.png][]

> **Tips**: 上述交换过程中 , 并不关心 B 变量后续的情况 , 更关心的是 V 这个变量的情况(这里的交换可以理解为赋值) , **CAS 可以理解成 CPU 的一个特殊指令 , 通过这个指令就可以一定程度的处理线程安全问题.**

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

### **1.2 CAS伪代码** ###

真实的 CAS 是一个原子硬件指令完成的 , 这个伪代码只是辅助理解 CAS 的工作流程.

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

> 两种典型的不是"**原子性**"的代码
> 
> 1.check and set (判定然后设定值)\[上面的 CAS 伪代码就是这种形式\]
> 
> 2.read and update(i++)

当多个线程对某个资源进行 CAS 操作 , 只有一个线程操作成功 , 但是并不会阻塞其他线程 , 其实线程只会收到操作失败的信号.

> CAS 可以视为是一种乐观锁(或者乐观锁是 CAS 的一种实现方式)

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

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

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

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

简而言之 , 就是因为**硬件给予了支持 , 软件层面才能做得到**.

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

### **1.4 CAS 的应用场景** ###

#### **1) 实现原子类** ####

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

典型的就是 AtomicInteger 类.

**代码示例:**

import java.util.concurrent.atomic.AtomicInteger;
    
    public class ThreadDemo14 {
        public static void main(String[] args) throws InterruptedException {
            AtomicInteger count = new AtomicInteger();
            Thread t1 = new Thread(() -> {
                for (int i = 0; i < 5000; i++) {
                    count.getAndIncrement();
                }
            });
            Thread t2 = new Thread(() -> {
                for (int i = 0; i < 5000; i++) {
                    count.getAndIncrement();
                }
            });
            t1.start();
            t2.start();
            t1.join();
            t2.join();
            System.out.println(count.get());
        }
    }

![c345b5a986f64bf2a030ec18a55a32b4.png][]

**伪代码实现:**

Class AtomicInteger{
        private int value;
        
        public int getAndIncrement(){
            int oldVaue = value;//相当于load操作
            while((CAS(value , oldvalue , oldvalue+1) != true){
                oldvalue = value;
                }
                return oldvalue;
        }
    }

oldervalue 相当于寄存器中的值 , value 相当于内存中的值.

> 正常情况下 , oldvalue 和 value 是一样的 , 可以直接执行 CAS 操作. 但有可能当oldvalue在内存中读取值后 , 线程发生了切换 , 另一个线程也修改了 value 的值 , 此时等这个线程重新回来 . oldvalue和value已经不相等了.

**图示:**

假设两个线程同时调用 getAndIncrement.

**(1). 两个线程都读取 value 的值到 oldvalue 中.**

![ff7a2a0caa654cafab119ea62a544b2b.png][]

**(2). 线程1先进行 CAS 操作. 由于 oldvalue 和 value的值相同 , 直接对 oldvalue 进行赋值.**

**Tips:**

>  *  CAS 是直接写内存的不是操作寄存器的.
>  *  CAS 读内存 , 比较 , 写内存 是一套原子的硬件指令.

![63f5abf9a60e4febbb7744d872720c66.png][]

**(3) 线程2再进行 CAS 操作 , 第一次 CAS 的时候 , oldvalue和value不相等 , 不能进行赋值 , 因此需要进入循环. 在循环中重新读取 value 的值赋值给 oldvalue.**

![0a67c7c85e81403ca977a7e3c1ae0ca6.png][]

**(4) 线程2 接下来进行第二次 CAS , 此时 oldvalue 和 value 相同 , 于是直接进行赋值操作.**

![ad0ec0273c8a402eaea48a4f3701d315.png][]

**(5) 线程1 和 线程2 返回各自的 oldvalue即可.**

通过上述代码就可以实现一个原子类 , 不需要使用重量级锁 , 就可以完成多线程的自增操作.

> 本来 check and set 这样的操作在代码角度不是原子的 , 但是在硬件层面上可以让一条指令完成这个操作 , 也就变成原子的了.

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

#### **2) 实现自旋锁(伪代码)** ####

public class SpinLock{
        private Thread owner = null;
    
        public void lock(){
            // 通过 CAS 观察当前锁是否被某个线程占有
            // 如果这个锁以及被别的线程占有 , 那么锁就自旋等待
            // 如果这个锁没有被别的线程占有 , 那么就把owner设为当前加锁的线程
            while(!CAS(this.owner , null , Thread.currentThread())){
            }
        }
    
        public void unlock(){
            this.owner = null;
        }
    }

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

### **1.5 CAS 的 ABA 问题** ###

ABA的问题:

假设存在两个线程 t1 和 t2 , 有一个共享变量 num , 初始值为 A.

接下来 , 线程 t1 想使用 CAS 把 num 值改成 Z , 那么就需要:

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

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

> 线程 t1 的 CAS 期望 num 不变就修改 , 但是 num的值已经被 t2 给改了. 只不过又改成了 A , 此时 t1 是否要将 num 的值更新为 Z 呢?

![b6c4ac3315a240dfa564262280304f4a.png][]

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

### **1.6 ABA问题引发的 BUG** ###

大部分情况下 t2 线程反复横跳对 t1 是否修改 num 是没有影响的 , 但不排除一些特殊情况.

假设小明有 100 存款 , 小明想从 ATM 机中取 50元. **不小心多按了几次** , 取款机创建了两个线程 , 并发的执行 -50 操作.

我们期望一个线程执行 -50 成功 , 另一个线程 -50 失败.

如果 CAS 的实现方式来完成这个扣款过程就会出现问题.

![24c68c6ade854eb8a152e528b9e77e94.png][]

**正常的过程:**

>  *  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相同 , 再次执行扣款操作.
> 
> **此时扣款操作执行了两次 , 这就是 ABA 问题引发的 BUG.**

**解决方案:**

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

**真正修改时:**

>  *  **在当前值等于旧值的前提下:**
>  *  如果当前版本号和之前读到的版本号相同 , 则修改数据 , 并把版本号 + 1.
>  *  如果当前版本号高于之前读到的版本号 , 就操作失败(认为数据已经被修改过了).

在 Java 标准库中提供了 AtomicStampedReference<E>类. 这个类可以对某个类进行包装 , 在内部就提供了上述描述的版本管理功能.

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

### 1.7 相关面试题 ###

**1. 讲解下自己理解的 CAS 机制.**

> CAS 全称 Compare and Swap , 相当于一个原子操作 , 同时完成"读取内存 比较数据是否相等 修改内存" 这三个步骤. 本质上是一条 CPU 指令.

**2. ABA 问题怎么解决?**

> 给要修改的数据引入一个版本号 , CAS 不仅要比较**当前值和旧值**是否相等 , 还要比较**版本号是否符合预期**. 在当前值和旧值相等的前提下 , 如果当前版本号和之前读到的版本号一致 , 就修改数据 , 并让版本号自增. 如果发现当前版本号比之前读的版本号大 , 操作失败.

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

## 2. Synchronized 基本原理 ##

### **2.1 基本特点** ###

结合上述所策略 , 我们可以总结出 Synchronized 具有以下特性(只考虑 jdk 1.8)

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

### 2.2 加锁过程 ###

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

![1ce75e5371784acabf366a2025a691a5.png][]

**1) 偏向锁**

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

偏向锁不是真的"**加锁**" , 只是给对象做一个"**偏向锁的标记**". 记录这个锁属于哪个线程.

如果后续没有其他线程来竞争该锁 , 那么就不用执行加锁操作(**由此避免了加锁的开销**)

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

> **Tips**: 偏向锁本质上相当于 "**延迟加锁**" , 能不加锁就不加锁 , 尽量避免不必要的加锁开销.
> 
> 但该做的标记还是得做 , 否则无法区分何时需要真正加锁.

举个例子: 假设小明有个女朋友叫小美 , 但由于没有其他女生对小明感兴趣 , 因此小美有恃无恐 , 一直拖着不和小明结婚. 直到有一天 , 出现一个对小明感兴趣的女生 , 小美慌了 , 立即和小明去领证.

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

**2)轻量级锁**

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

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

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

**何为"自适应"?**

自选操作会让 CPU 一直空转 , 比较浪费 CPU 资源.

因此此处的自旋不会一直进行 , 达到一定次数或时间后 , 就不在自旋了.也是"自适应"

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

**3) 重量级锁**

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

此处的重量级锁就是指内核提供的 mutex.

>  *  执行加锁操作 , 先进入内核态.
>  *  在内核态判定当前锁是否被占用.
>  *  如果该锁没有被占用 , 则加锁成功 , 并切换会用户态.
>  *  如果该锁被占用了 , 则加锁失败 , 此时线程进入锁的等待队列(挂起) , 等待被操作系统唤醒.
>  *  经过漫长的等待 , 该锁被其他线程释放 , 操作系统也想起了这个被挂起的线程 , 于是唤醒这个线程重新尝试获取锁.

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

### 2.3 其他的优化操作 ###

**锁消除**

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

有些应用程序的代码块 , 在单线程的情况下也用到了**synchronized**(例如 StringBuffer)

StringBuffer str = new StringBuffer();
    str.append("H");
    str.append("e");
    str.append("l");
    str.append("l");
    str.append("o");

此时每次调用 append 操作都会涉及到**加锁/解锁** , 在单线程情况下是不必要的 , 白白浪费资源开销.

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

**锁粗化**

一段操作中如果多次进行加锁操作 , 编译器 + JVM 会自动进行锁的粗化.

锁的力度: 粗和细

![be96518b31a54f5c8454f43481d01360.png][]

实际开发过程中使用细粒度锁 , 是希望释放锁的时候其他线程能使用锁.

但如果实际上并没有那么多的线程抢占锁 , 这种情况下 JVM 就会把锁粗化 , 频繁的申请释放锁.

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

[d0cd85e69a244a22a8c2a97f14682312.gif]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/27/e816a6ed028640ff97f3b3a12a7dfbe9.png
[c4304daa3a1846adadc000eea43efbf4.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/27/fd0daee7f43742e589c309376bc986e3.png
[1254c5b119a44cf0ae350489fb7736ad.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/27/1d169b2e2a434f9782e3c9aa9506c736.png
[4366a93aaa3142b5a0f16c7a2200339b.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/27/8476f83c58e946ff9683f2e47f36b176.png
[52a3437a932f4621b25533c330f7c6cb.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/27/135c18aa878343ce92840bb1d1ef884d.png
[14aa2f0648ae44a299b8f9832af57d2c.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/27/da4a1ade32944088a71e3217783e7a77.png
[0a84a36dd05c440e837fc8d63dd5ec07.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/27/59372cd212a94c3db80ae87a0732b8ea.png
[c345b5a986f64bf2a030ec18a55a32b4.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/27/744de4a9dd49438a9642ee5d2db2f871.png
[ff7a2a0caa654cafab119ea62a544b2b.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/27/a1890928ce8846efaea0d96c42a48dfc.png
[63f5abf9a60e4febbb7744d872720c66.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/27/e8a2684050c5424f9bf8c369f56ca003.png
[0a67c7c85e81403ca977a7e3c1ae0ca6.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/27/c71fcf009e5d444695026e9f30e72519.png
[ad0ec0273c8a402eaea48a4f3701d315.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/27/e037fdca7deb4bdfb7730e7e235976e5.png
[b6c4ac3315a240dfa564262280304f4a.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/27/8bd6385ce1b044e696a56e7cf33d4eec.png
[24c68c6ade854eb8a152e528b9e77e94.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/27/9130b31ec1d3482185dfb440f0a70785.png
[1ce75e5371784acabf366a2025a691a5.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/27/b77b4953c5cb468c8e5525b33706c2db.png
[be96518b31a54f5c8454f43481d01360.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/27/e92bcba1fe0f405883cff51f199f2d86.png