目录

常见的锁策略

乐观锁 vs 悲观锁

悲观锁:

乐观锁：

读写锁

重量级锁 vs 轻量级锁

自旋锁（Spin Lock）

公平锁 vs 非公平锁

可重入锁 vs 不可重入锁

CAS

什么是 CAS

CAS 是怎么实现的

CAS 有哪些应用

1) 实现原子类

2) 实现自旋锁

CAS 的 ABA 问题

什么是 ABA 问题

ABA 问题引来的 BUG

 解决方案

Synchronized 原理

基本特点

加锁工作过程

其他的优化操作

锁消除

锁粗化

常见的锁策略

乐观锁 vs 悲观锁

悲观锁:

乐观锁：

举个栗子 : 同学 A 和 同学 B 想请教老师一个问题 .

同学 A 认为 " 老师是比较忙的 , 我来问问题 , 老师不一定有空解答 ". 因此同学 A 会先给老师发消息 : " 老师你忙嘛? 我下午两点能来找你问个问题嘛 ?" ( 相当于加锁操作 ) 得到肯定的答复之后 , 才会真的来问问题 .如果得到了否定的答复, 那就等一段时间 , 下次再来和老师确定时间 . 这个是悲观锁 .

同学 B 认为 " 老师是比较闲的 , 我来问问题 , 老师大概率是有空解答的 ". 因此同学 B 直接就来找老师 .( 没加锁, 直接访问资源 ) 如果老师确实比较闲 , 那么直接问题就解决了 . 如果老师这会确实很忙 , 那么同学 B也不会打扰老师, 就下次再来 ( 虽然没加锁 , 但是能识别出数据访问冲突 ). 这个是乐观锁 .

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

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

假设我们需要多线程修改 "用户账户余额".

设当前余额为 100. 引入一个版本号 version, 初始值为 1. 并且我们规定 " 提交版本必须大于记录 当前版本才能执行更新余额 "

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

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

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

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

读写锁

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

读写锁（readers-writer lock），看英文可以顾名思义，在执行加锁操作时需要额外表明读写意图，复 数读者之间并不互斥，而写者则要求与任何人互斥。

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

读写锁特别适合于 "频繁读, 不频繁写" 的场景中. (这样的场景其实也是非常广泛存在的).

Synchronized 不是读写锁.

重量级锁 vs 轻量级锁

• 大量的内核态用户态切换
• 很容易引发线程的调度

• 少量的内核态用户态切换.
• 不太容易引发线程调度.

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

自旋锁（Spin Lock）

按之前的方式，线程在抢锁失败后进入阻塞状态，放弃 CPU，需要过很久才能再次被调度.

但实际上, 大部分情况下，虽然当前抢锁失败，但过不了很久，锁就会被释放。没必要就放弃 CPU. 这个时候就可以使用自旋锁来处理这样的问题.

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

如果获取锁失败, 立即再尝试获取锁, 无限循环, 直到获取到锁为止. 第一次获取锁失败, 第二次的尝试会在极短的时间内到来.

一旦锁被其他线程释放, 就能第一时间获取到锁.

理解自旋锁 vs 挂起等待锁

想象一下 , 去追求一个女神 . 当男生向女神表白后 , 女神说 : 你是个好人 , 但是我有男朋友了 ~~

挂起等待锁 : 陷入沉沦不能自拔 .... 过了很久很久之后 , 突然女神发来消息 , " 咱俩要不试试 ?" ( 注意 ,这个很长的时间间隔里, 女神可能已经换了好几个男票了 ).

自旋锁 : 死皮赖脸坚韧不拔 . 仍然每天持续的和女神说早安晚安 . 一旦女神和上一任分手 , 那么就能立刻抓住机会上位.

• 优点: 没有放弃 CPU, 不涉及线程阻塞和调度, 一旦锁被释放, 就能第一时间获取到锁.
• 缺点: 如果锁被其他线程持有的时间比较久, 那么就会持续的消耗 CPU 资源. (而挂起等待的时候是不消耗 CPU 的).

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

公平锁 vs 非公平锁

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

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

• 操作系统内部的线程调度就可以视为是随机的. 如果不做任何额外的限制, 锁就是非公平锁. 如果要想实现公平锁, 就需要依赖额外的数据结构, 来记录线程们的先后顺序.
• 公平锁和非公平锁没有好坏之分, 关键还是看适用场景.

synchronized 是非公平锁.

可重入锁 vs 不可重入锁

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

比如一个递归函数里有加锁操作，递归过程中这个锁会阻塞自己吗？如果不会，那么这个锁就是可重入锁（因为这个原因可重入锁也叫做递归锁）。

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

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

CAS

什么是 CAS

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

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

CAS 可以视为是一种乐观锁. (或者可以理解成 CAS 是乐观锁的一种实现方式)。

CAS 是怎么实现的

简而言之，是因为硬件予以了支持，软件层面才能做到。

CAS 有哪些应用

1) 实现原子类

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

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

AtomicInteger atomicInteger = new AtomicInteger(0);
// 相当于 i++
atomicInteger.getAndIncrement();

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

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

2) 实现自旋锁

基于 CAS 实现更灵活的锁, 获取到更多的控制权.

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;}
}

什么是 ABA 问题

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

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

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

ABA 问题引来的 BUG

解决方案

这就好比 , 判定这个手机是否是翻新机 , 那么就需要收集每个手机的数据 , 第一次挂在电商网站上的手机记为版本1, 以后每次这个手机出现在电商网站上 , 就把版本号进行递增 . 这样如果买家不在意这是翻新机, 就买 . 如果买家在意 , 就可以直接略过 .

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

Synchronized 原理

基本特点

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

加锁工作过程

1) 偏向锁

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

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

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

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

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

但是该做的标记还是得做的, 否则无法区分何时需要真正加锁.

2) 轻量级锁

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

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

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

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

因此此处的自旋不会一直持续进行, 而是达到一定的时间/重试次数, 就不再自旋了.

也就是所谓的 "自适应"

3) 重量级锁

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

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

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

其他的优化操作

锁消除

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

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

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

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

锁粗化

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

 举个栗子理解锁粗化

滑稽老哥当了领导 , 给下属交代工作任务 :

方式一 :

• 打电话, 交代任务1, 挂电话.
• 打电话, 交代任务2, 挂电话.
• 打电话, 交代任务3, 挂电话.

方式二 :

• 打电话, 交代任务1, 任务2, 任务3, 挂电话.

显然 , 方式二是更高效的方案 .