「JVM 高效并发」锁优化

news2025/1/13 10:33:59

为了线程间更高效的共享数据及解决竞争问题，提高程序执行效率，JDK 6 做了大量锁优化，如适应性自旋（Adaptive Spinning）、锁消除（Lock Elimination）、锁膨胀（Lock Coarsening）、轻量级锁（Lightweight Locking）、偏向锁（Biased Locking）等；

文章目录

- - 1. 自旋锁与自适应自旋
  - 2. 锁消除
  - 3. 锁粗化
  - 4. 轻量级锁
  - 5. 偏向锁

1. 自旋锁与自适应自旋

自旋锁，让后面请求锁的线程稍等一会，但不放弃处理器的执行时间，看持有锁的线程是否很快释放锁；为了让线程等待，需让线程执行一个忙循环（自旋）；

自旋等待不能代替阻塞，它虽然避免了线程切换的开销，但会占用处理器时间；锁被占用的时间很短时自旋等待效果很好，但长时间自旋的线程会浪费 CPU 资源；

-XX:PreBlockSpin，设置自旋次数，超过后使用传统方式挂起线程；

自适应自旋，自旋时间不是固定的，而是由前一次在同一锁上自旋时间及锁的拥有者的状态来决定（上次自旋成功获得锁，则可能允许自旋等待更长的时间；上次自旋失败，则可能不在允许自旋等待）；

2. 锁消除

锁消除，JVM 在即时编译期对一些代码要求同步，但被检测到不可能存在共享数据竞争（逃逸分析，堆上所有数据都不会逃逸出线程，就可以把它们当做栈上数据对待，即线程私有）的锁进行消除；

JDK 5 之前同步代码示例

public String concatString(String s1, String s2, String s3) {
    return s1 + s2 + s3;
}

javac 编译后的连接操作

public String concatString(String s1, String s2, String s3) {
    StringBuffer sb = new StringBuffer();
    sb.append(s1);
    sb.append(s2);
    sb.append(s3);
    return sb.toString();
}

每个 append() 方法内部都是一个同步块，锁对象是 sb；经过逃逸分析，发现 sb 的所有引用都不会逃逸出 concatString() 方法，其他线程无法访问到它，因此可以在即时编译阶段安全的消除锁；（在解释执行存在锁，在编译执行没有锁；JDK 5 之后改用非线程安全的 StringBuilder 就不会自动加锁了）；

3. 锁粗化

原则上编写代码时，推荐奖同步块的作用范围限制得尽量小，只有共享数据的实际作用域才进行同步，这样即使存在锁竞争，也可尽可能快地拿到锁；

但若频繁对同一个对象反复加锁和解锁，甚至在循环体上加锁，即使没有线程竞争，频繁互斥操作也会导致不必要的性能损耗；因此 JVM 会直接把加锁同步的范围扩展（粗化）到整个操作序列的外部；（如上例，直接在第一个 append() 之前加锁，在最后一个 append() 之后解锁）；

4. 轻量级锁

不是用来代替重量级锁的，而是在没有多线程竞争时，减少传统重量级锁的操作系统互斥产生的性能消耗；

请添加图片描述

在线程即将进入同步块时，若此同步对象还没有被锁定（01 状态），JVM 会先在当前线程的栈帧中建立一个锁记录（Lock Record）空间，用于存储锁对象目前 Mark Work 的拷贝（Displace Mark Word）；

然后 JVM 尝试使用 CAS 操作把对象的 Mark Word 更新为执行 Lock Record 的指针；若 CAS 操作成功，代表该线程拥有了这个对象的锁（对象 Mark Word 的锁标志为将转变为 00 状态）；

若 CAS 操作失败，代表至少有一个线程与当前线程竞争获取该对象的锁，JVM 会先检查对象的 Mark Word 是否指向当前线程的栈帧；若是，说明当前线程已拥有这个对象的锁，直接进入同步块继续执行即可；若否，则说明这个对象的锁已经被其他线程占有，若出现两条以上线程占用同一个锁，则轻量级锁不再有效，必须膨胀为重量级锁，锁标志状态变为 10（此时 Mark Word 中存储的是指向重量级锁，互斥量的指针），等待锁的线程必须进入阻塞状态；

轻量级锁的解锁过程同样使用 CAS 操作，若对象的 Mark Word 任然指向线程的锁记录，就用 CAS 操作把对象当前的 Mark Word 和线程中复制的 Displaced Mark Word 替换回来；若成功，则整个同步过程顺利完成，否则说明有其他线程尝试过获取锁，就要释放锁并唤醒被挂起的线程；

轻量级锁的适用场景是：绝大部分锁在整个同步周期内部存在竞争；没有竞争的情况下，轻量级锁通过 CAS 操作可以成功避免使用互斥量的开销；但若竞争存在，除了互斥量本身的开销，额外的 CAS 操作开销会让消耗比传统重量级锁更大；

5. 偏向锁

JDK 6 引入的锁优化措施；用于消除数据在无竞争情况下的同步原语；（轻量级锁是消除无竞争状态下的互斥量）；

如果第一个获得锁的线程在接下来的执行中一致没有其他线程竞争，则持有偏向锁，线程永远不需要再进行同步；

锁对象第一次被线程获取时，JVM 会把对象头中的标志位设置为 01，把偏向模式设置为 1，表示进入偏向模式；同时使用 CAS 操作把获得这个锁的线程的 ID 记录在对象的 Mark Word 中，若 CAS 操作成功，持有偏向锁的线程以后每次进入这个锁相关的同步块都不再进行同步操作（加锁、解锁、Mark Word 更新操作等）；

一旦出现另外的线程去尝试获取这个锁，偏向模式立刻结束；若对象未被锁定，撤销偏向（偏向模式置为 0）后标志位恢复到未锁定（01），若对象已被锁定，则标志位置为 00（使用轻量级锁）；

请添加图片描述

当一个对象已经计算过一次一致性哈希码，它就无法再进入偏向锁状态；而当一个对象正处理偏向锁状态，又收到计算一致性哈希码请求时，它的偏向状态会立即测校，且锁会膨胀为重量级锁，对象头指向重量级锁的位置（代表重量级锁的 ObjectMonitor 类里可以记录非加锁状态下的 Mark Word，也可以存储原来的哈希码）；

若程序中大多数的锁总是被多个不同线程访问，偏向模式就是多余的，可能使用 -XX:-UseBiasedLocking 禁用偏向锁优化反而可使性能提升；