【JUC】synchronized 原理

发表于2021-03-20更新于2022-03-11字数统计3.2k阅读时长18分阅读次数

synchronized 原理

Monitor

Monitor 被翻译为监视器或管程，是 JVM 实现的对象。每个 Java 对象都可以关联一个 Monitor 对象，如果使用 synchronized(obj) 给对象 obj 上锁（重量级）之后，obj 的对象头的 Mark Word 就会保存指向其对应的 Monitor 对象的指针。

Mark Word 结构（运行时元数据）

1
2
3
4
5
6
7
8
9
10
11
12
13
|-------------------------------------------------------|--------------------|
|                 Mark Word (32 bits)                   |        State       |
|-------------------------------------------------------|--------------------|
| hashcode:25         | age:4 | biased_lock:0 | 01      | Normal             |
|-------------------------------------------------------|--------------------|
| thread:23 | epoch:2 | age:4 | biased_lock:1 | 01      | Biased             |
|-------------------------------------------------------|--------------------|
|              ptr_to_lock_record:30          | 00      | Lightweight Locked |
|-------------------------------------------------------|--------------------|
|           ptr_to_heavyweight_monitor:30     | 10      | Heavyweight Locked |
|-------------------------------------------------------|--------------------|
|                                             | 11      | Marked for GC      |
|-------------------------------------------------------|--------------------|

普通对象的完整对象头信息：

1
2
3
4
5
|--------------------------------------------------------------|
|                    Object Header (64 bits)                   |
|------------------------------------|-------------------------|
|         Mark Word (32 bits)        |   Klass Word (32 bits)  |
|------------------------------------|-------------------------|

数组对象的完整对象头信息：

1
2
3
4
5
|---------------------------------------------------------------------------------|
|                          Object Header (96 bits)                                |
|--------------------------------|-----------------------|------------------------|
|        Mark Word(32bits)       |   Klass Word(32bits)  |  array length(32bits)  |
|--------------------------------|-----------------------|------------------------|

重量级锁

当前线程在获取到锁后，就会将 obj 的 Mark Word 内原本存储的信息（hashcode、age 等）暂存到 Monitor 对象中，然后在 Mark Word 中保存这个 Monitor 的物理地址 ptr_to_heavyweight_monitor（这样其他想加锁的线程就能通过该指针访问到 Monitor 对象），注意：该操作是通过 Unsafe 类保证 CAS 的原子性。同时 Monitor 对象中的 Owner 将指向该线程 Thread-0。

当解锁时，会再将暂存在 Monitor 中的 Mark Word 信息再 CAS 交换回 obj 的对象头中。

  • 轻量级锁会在锁记录中记录 hashCode 等值
  • 重量级锁会在 Monitor 中记录 hashCode 等值

加锁流程：

image-20220304151528662

  • 刚开始 Monitor 中 Owner 为 null
  • 当 Thread-2 执行 synchronized(obj) 就会将 obj 对象对应的 Monitor 的所有者 Owner 置为 Thread-2。一个 Monitor 中只能有一个 Owner
  • 在 Thread-2 上锁的过程中，如果 Thread-3，Thread-4，Thread-5 也来执行 synchronized(obj)，就会进入EntryList 进入 BLOCKED 状态
  • Thread-2 执行完同步代码块的内容，然后唤醒 EntryList 中等待的线程来竞争锁，竞争是非公平的
  • 图中 WaitSet 中的 Thread-0，Thread-1 是之前获得过锁，但是主动调用了 wait() 方法而进入 WAITING 状态的线程。等待持有锁的线程调用 notify() 方法，就会随机从 WaitSet 中选取一个线程唤醒，并放入 EntryList 中阻塞等待当前线程释放锁后一起竞争锁

注意：

  • synchronized 必须是进入同一个对象的 Monitor 才有上述的效果
  • 不加 synchronized 的对象不会关联监视器，不遵从以上规则

轻量级锁

轻量级锁的使用场景：如果一个对象虽然有多线程要加锁，但加锁的时间是错开的（也就是没有竞争），那么可以使用轻量级锁来优化。

轻量级锁适合于多线程加锁时间交错进行，不会大量竞争。这时将重量级的Monitor 加锁过程简化为仅仅 CAS 操作 obj 对象的 Mark Word 是否没被轻量级锁占用。这样在线程竞争不激烈的情况下就可以节省很多使用 Monitor 带来的性能损耗，直接使用 CAS 判断 obj 的状态即可，显然节省了很多时间。

轻量级锁在发生竞争时，会首先通过多次的自旋尝试 CAS 获取锁，不会阻塞线程。如果多次自旋仍然失败，则会膨胀到重量级锁。

轻量级锁对使用者是透明的，即语法仍然是 synchronized(obj)。

假设有两个方法同步块，利用同一个对象加锁：

1
2
3
4
5
6
7
8
9
10
11
12
static final Object obj = new Object();
public static void method1() {
    synchronized( obj ) {
        // 同步块 A
        method2();
    }
}
public static void method2() {
    synchronized( obj ) {
        // 同步块 B
    }
}
  1. 创建锁记录（Lock Record）对象，每个线程的栈帧都会包含一个锁记录的结构，内部可以存储锁定对象的 Mark Word

image-20220304153924392

  1. 内部可以存储锁定对象的 Mark Word

image-20220304153933210

  1. 当线程 Thread-0 想加锁时，就会尝试 CAS 交换锁对象中的地址值与 obj 的 Mark Word 值。如果 CAS 换成功，对象头中存储了锁记录地址和状态 00，表示由该线程给对象加锁，这时图示如下

image-20220304154025227

  1. 如果 CAS 加锁失败（发现 obj 里的 Mark Word 的状态位 01 已经被改变为了 00），有两种情况：
    1. 如果是其它线程已经持有了该 Object 的轻量级锁，这时表明有竞争，进入锁膨胀过程
    2. 如果是自己执行了 synchronized 锁重入，那么再添加一条 Lock Record 作为重入计数

image-20220304154419241

  1. 当退出 synchronized 代码块（解锁）时，如果有取值为 null 的锁记录，表示有重入，这时重置锁记录，表示重入计数减一

image-20220304154457411

  1. 当退出 synchronized 代码块（解锁）时，锁记录的值不为 null，这时使用 CAS 将 Mark Word 的值恢复给对象头
    1. 成功，则解锁成功
    2. 失败，说明轻量级锁进行了锁膨胀或已经升级为重量级锁，进入重量级锁解锁流程（见下文）

锁膨胀

如果在尝试加轻量级锁的过程中，CAS 操作无法成功，这时一种情况就是有其它线程为此对象加上了轻量级锁（有竞争），这时需要进行锁膨胀，将轻量级锁变为重量级锁。

  1. 当 Thread-1 进行轻量级加锁时，Thread-0 已经对该对象加了轻量级锁

image-20220304155500980

  1. 这时 Thread-1 加轻量级锁失败，进入锁膨胀流程
    1. 即为 Object 对象申请 Monitor 锁，让 Object 指向重量级锁地址
    2. 然后自己进入 Monitor 的 EntryList，进入 BLOCKED 状态

image-20220304155554944

  1. 当 Thread-0 退出同步块解锁时，使用 CAS 将 Mark Word 的值恢复给对象头，失败。这时会进入重量级解锁流程，即按照 Monitor 地址找到 Monitor 对象，设置 Owner 为 null，唤醒 EntryList 中 BLOCKED 线程

自旋优化

重量级锁竞争的时候，还可以使用自旋来进行优化，如果当前线程自旋成功（即这时候持锁线程已经退出了同步块，释放了锁），这时当前线程就可以避免阻塞。

即通过少量的几次自旋尝试获取锁，如果持有锁的线程执行任务时间很短，那么这几次自旋后就可以直接获取到锁了，也就无需再阻塞等待了。

  • 自旋会占用 CPU 时间，单核 CPU 自旋就是浪费，多核 CPU 自旋才能发挥优势。
  • 在 Java 6 之后自旋锁是自适应的，比如对象刚刚的一次自旋操作成功过，那么认为这次自旋成功的可能性会高，就多自旋几次；反之，就少自旋甚至不自旋，总之，比较智能。
  • Java 7 之后不能控制是否开启自旋功能

偏向锁

轻量级锁在没有竞争时（就自己这个线程），每次重入仍然需要执行 CAS 操作判断 obj 是否被加锁。能不能把这一步也节省掉呢？

Java 6 中引入了偏向锁来做进一步优化：只有第一次使用 CAS 将线程 ID 设置到对象的 Mark Word 头，之后发现这个线程 ID 是自己的就表示没有竞争，不用重新 CAS。以后只要不发生竞争，这个对象就归该线程所有。

为了减少 CAS 操作，引入了偏向锁，每次只需要判断 obj 的 Mark Word 中的 thread 保存线程 id 是否等于本线 程 id。偏向锁适合于只有一个线程进行加锁，其他线程不怎么来加锁。这时就能把每次加锁的 CAS 操作也节省掉。

轻量级锁：

image-20220304160931596

改为偏向锁后：

image-20220304160945997

可以看出，如果一直是一个线程在访问，就能节省了很多 CAS 的操作。

image-20220304161125279

一个对象创建时：

  • 如果开启了偏向锁（默认开启），那么对象创建后，Mark Word值为 0x05 即最后 3 位为 101，这时它的thread、epoch、age 都为 0
  • 偏向锁默认是延迟的，不会在程序启动时立即生效，如果想避免延迟，可以加 VM 参数 -XX:BiasedLockingStartupDelay=0 来禁用延迟。如果没有开启偏向锁，那么对象创建后，markword 值为 0x01 即最后 3 位为 001，这时它的 hashcode、age 都为 0，第一次用到 hashcode 时才会赋值

偏向锁一旦被某个线程使用后就会在 Mark Word 中保存该线程的 id（由操作系统分配），即使这个锁被释放了，也仍然会保存着该信息。之后该线程再次试图加锁时就不需要再 CAS 判断了。

撤销 - 调用对象 hashCode

调用了对象的 hashCode，但偏向锁的对象 Mark Word 中存储的是线程 id，如果调用 hashCode() 会导致偏向锁被撤销，并且该对象之后都不会再使用偏向锁了

  • 轻量级锁会在锁记录中记录 hashCode
  • 重量级锁会在 Monitor 中记录 hashCode

在调用 hashCode 后使用偏向锁，记得去掉 -XX:-UseBiasedLocking

撤销 - 其它线程使用对象

当有其它线程使用偏向锁对象后，会将偏向锁升级为轻量级锁，并且修改 Mark Word ，使得状态 101 变为 001，代表该对象目前不再可偏向了。但是如果该对象被同一个线程作为 20 次的轻量级锁后，就会再次偏向为该线程（重新偏向）。

注意：撤销是针对这个类的所有对象而言的。如果该类的所有对象累计 40 次偏向错误，JVM 就会让该类的所有对象都取消偏向功能，之后一律使用轻量级锁。

所以对于会产生并发的情况，建议直接关闭偏向锁

这里指的使用不是竞争，一旦竞争立即升级为重量级锁。

撤销 - 调用 wait/notify

当本线程调用 wait/notify 时，会将偏向锁升级为重量级锁。

批量重偏向

如果对象虽然被多个线程访问，但没有竞争，这时偏向了线程 T1 的对象仍有机会重新偏向 T2，重偏向会重置对象
的 Thread ID。

  • 当撤销偏向锁阈值超过 20 次后，JVM 会这样觉得，我是不是偏向错了呢，于是会在给这些对象加锁时重新偏向至加锁线程
  • 当撤销偏向锁阈值超过 40 次后，JVM 会这样觉得，自己确实偏向错了，根本就不该偏向。于是整个类的所有对象都会变为不可偏向的，新建的对象也是不可偏向的

锁消除

有一些 JVM 厂商的 JIT 即时编译器在进行代码优化时会将一些不可能被共享的锁进行消除（Hotspot 没有实现锁消除）

总结

  • 重量级锁每次都需要将 obj 的 Mark Word 信息与 Monitor 地址进行 CAS，性能最低
  • 轻量级锁不再使用 Monitor，而是将 obj 的 Mark Word 与该线程 Thread 对象的锁记录进行 CAS，性能高一些。适用于线程之间竞争不激烈的情况。但仍然加锁时需要每次都 CAS 判断 obj 是否已经被加锁，也会有一定的性能损耗。当使用轻量级锁发生锁竞争时，会首先多次的自旋 CAS 尝试获取锁，如果多次尝试仍然失败，则为该轻量级锁会升级为重量级锁，还是会使用 Monitor
  • 偏向锁只需要判断 obj 中 Mark Word 的 thread 字段代表的线程 id 是否等于本线程，省去了 CAS 操作。适用于一个对象只由一个线程加锁，其他线程不怎么会加锁。性能最高。在明确知道有并发时可以手动关闭偏向锁

不论原本的锁是轻量级还是偏向锁，只要有线程竞争，就会立刻升级为重量级锁。但如果线程间交错开加锁，就不会升级为重量级锁，同时修改 Mark Word ，使得状态 101 变为 001，代表该对象目前不再可偏向了。但是如果该对象被同一个线程作为 20 次的轻量级锁后，就会再次偏向为该线程（重新偏向），如果该类的所有对象累计 40 次偏向错误，JVM 就会让该类的所有对象都取消偏向功能，之后一律使用轻量级锁。

wait/notify 原理

image-20220304154713100

  • Owner 线程发现条件不满足，调用 wait 方法，即可进入 WaitSet 变为 WAITING 状态
  • BLOCKED 和 WAITING 的线程都处于阻塞状态，不占用 CPU 时间片
  • BLOCKED 线程会在 Owner 线程释放锁时唤醒
  • WAITING 线程会在 Owner 线程调用 notify 或 notifyAll 时唤醒，但唤醒后并不意味者立刻获得锁，仍需进入EntryList 重新竞争