【多线程】synchronized 原理

✨个人主页：bit me👇
✨当前专栏：Java EE初阶👇

❄️一. 基本特点

1. 开始时是乐观锁, 如果锁冲突频繁, 就转换为悲观锁.(自适应)

2. 开始是轻量级锁实现, 如果锁被持有的时间较长, 就转换成重量级锁. (自适应)

3. 实现轻量级锁的时候大概率用到的自旋锁策略

4. 是一种不公平锁

5. 是一种可重入锁

6. 不是读写锁

synchronized 是怎样进行自适应的？(锁膨胀 / 升级的过程)

---

☁️二. 加锁工作过程

synchronized 在加锁的时候要经历的几个阶段：

• 无锁(没加锁)
• 偏向锁(刚开始加锁，未产生竞争的时候)
• 轻量级锁(产生锁竞争了)
• 重量级锁(锁竞争的更激烈)

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 等方法，都是带有 synchronized ，如果上述代码都只是在同一个线程中执行的，此时就没必要加锁了，JVM 就悄悄地把锁给去掉了。

不是所有的情况下都会触发，大部分情况不能触发的

锁粗化：

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

锁的粒度: 粗和细

synchronized 包含的范围是大还是小。范围越大，粒度越粗；范围越小，粒度越细。

锁的粒度细了，能更好的提高线程并发，但是也会增加 “加锁解锁” 次数。

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

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

举个例子理解锁粗化

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

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

 
方式二:

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

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