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

"把自己锁死" ：一个线程没有释放锁, 然后又尝试再次加锁
// 第一次加锁, 加锁成功
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 是一个局部变量，在栈上，每个线程有自己的栈)

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

CAS 是直接读写内存的，而不是操作寄存器

CAS 的读内存，比较，写内存操作是一条硬件指令，是原子的

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

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

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，还是经历了一个变化过程

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

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 锁分为无锁、偏向锁、轻量级锁、重量级锁状态。会根据情况，进行依次升级

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 会自动进行锁的粗化

锁的粒度: 粗和细

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

但是实际上可能并没有其他线程来抢占这个锁. 这种情况 JVM 就会自动把锁粗化，避免频繁申请释放锁

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