J.U.C Review - volatile / synchronized / 锁 深入剖析

本文主要是介绍J.U.C Review - volatile / synchronized / 锁 深入剖析，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

---

几个基本概念

内存可见性

在Java内存模型（JMM）中，每个线程都有自己的工作内存，这其中存储了从主内存中复制的共享变量的副本。内存可见性指的是，当一个线程修改了共享变量时，其他线程能够及时看到这个修改结果。

例如，假设线程A更新了某个共享变量，而线程B试图读取这个变量，如果没有适当的内存同步机制，线程B可能无法立即看到线程A的修改。这种现象可能导致并发问题，尤其是在多线程环境下。

重排序

为了提高程序性能，编译器和处理器可能会对指令进行重排序，重新调整指令的执行顺序。重排序可能发生在不同的阶段，如编译阶段的编译器重排序，或在运行时的处理器重排序。这种重排序通常不会改变单线程程序的语义，但在多线程环境下，如果没有正确的同步机制，可能会导致预期之外的结果。

happens-before规则

happens-before规则是Java内存模型中的一种保证规则，用于确保在多线程环境下，某些操作的执行顺序是可预期的。遵循happens-before规则的代码能够确保JVM在多线程执行时能够正确处理指令的执行顺序。

volatile的内存语义

在Java中，volatile关键字具有独特的内存语义，主要提供以下两个功能：

1. 保证变量的内存可见性： 当一个线程修改了volatile变量，JMM会确保该修改立即对其他线程可见。
2. 禁止volatile变量与普通变量的重排序： 这种增强的内存语义是从Java 5开始引入的，确保了更严格的指令执行顺序。

内存可见性

下面是一段使用volatile关键字的示例代码：

public class VolatileExample {int a = 0;volatile boolean flag = false;public void writer() {a = 1; // step 1flag = true; // step 2}public void reader() {if (flag) { // step 3System.out.println(a); // step 4}}
}

在这段代码中，flag变量被volatile修饰。内存可见性保证，当一个线程对volatile变量进行写操作时（例如step 2），该线程的本地内存中的值会立即刷新到主内存。其他线程在读取volatile变量时（例如step 3），JMM会确保线程从主内存读取最新的值，而不是使用自己工作内存中的旧值。

通过这种机制，volatile关键字提供了与锁相似的内存可见性效果：volatile变量的写操作类似于锁的释放，而volatile变量的读操作类似于锁的获取。

假设线程A先执行writer方法，接着线程B执行reader方法。由于flag是volatile变量，线程B在step 3读取到的是线程A在step 2更新后的值。这种行为可以通过以下时间线来表示：

1. 线程A执行step 1 (a = 1)
2. 线程A执行step 2 (flag = true) [刷新主内存]
3. 线程B执行step 3 (读取flag = true)
4. 线程B执行step 4 (读取a = 1)

如果flag没有被volatile修饰，线程B可能会读取到未更新的值，从而导致逻辑错误。

---

禁止重排序

在JSR-133规范发布之前的旧Java内存模型中，volatile变量和普通变量之间是允许重排序的。这可能导致错误的程序执行顺序。例如，上述代码在旧内存模型中可能会被重排序为：

1. 线程A执行step 2 (flag = true)
2. 线程B执行step 3 (读取flag = true)
3. 线程B执行step 4 (读取a = 0)
4. 线程A执行step 1 (a = 1)

这种情况下，尽管flag的可见性得到了保证，但线程B可能会错误地读取到旧的变量a的值。

为了避免这种情况，JSR-133增强了volatile的内存语义，确保volatile变量的读写操作不能与其他变量的操作重排序。JVM通过在生成字节码时插入内存屏障来实现这一点。

内存屏障

内存屏障是一种底层机制，用于阻止指令重排序并确保内存的正确同步。内存屏障主要分为两种：读屏障（Load Barrier） 和 写屏障（Store Barrier）。这些屏障有两个主要作用：

1. 阻止屏障两侧的指令重排序。
2. 强制将写缓冲区或缓存中的数据刷新到主内存，或者使缓存中的数据失效。

编译器在生成字节码时，会根据需要在指令序列中插入内存屏障。例如：

• 在每个volatile写操作前插入一个StoreStore屏障。
• 在每个volatile写操作后插入一个StoreLoad屏障。
• 在每个volatile读操作后插入一个LoadLoad屏障。
• 在每个volatile读操作后再插入一个LoadStore屏障。

这些屏障确保了指令执行的顺序性，并保证了volatile变量的内存语义。

再逐个解释一下这几个屏障。注：下述Load代表读操作，Store代表写操作

LoadLoad屏障：对于这样的语句Load1; LoadLoad; Load2，在Load2及后续读取操作要读取的数据被访问前，保证Load1要读取的数据被读取完毕。

StoreStore屏障：对于这样的语句Store1; StoreStore; Store2，在Store2及后续写入操作执行前，这个屏障会把Store1强制刷新到内存，保证Store1的写入操作对其它处理器可见。

LoadStore屏障：对于这样的语句Load1; LoadStore; Store2，在Store2及后续写入操作被刷出前，保证Load1要读取的数据被读取完毕。

StoreLoad屏障：对于这样的语句Store1; StoreLoad; Load2，在Load2及后续所有读取操作执行前，保证Store1的写入对所有处理器可见。它的开销是四种屏障中最大的（冲刷写缓冲器，清空无效化队列）。在大多数处理器的实现中，这个屏障是个万能屏障，兼具其它三种内存屏障的功能

对于连续多个volatile变量读或者连续多个volatile变量写，编译器做了一定的优化来提高性能，比如：

第一个volatile读;

LoadLoad屏障；

第二个volatile读；

LoadStore屏障

再介绍一下volatile与普通变量的重排序规则:

1. 如果第一个操作是volatile读，那无论第二个操作是什么，都不能重排序；

2. 如果第二个操作是volatile写，那无论第一个操作是什么，都不能重排序；

3. 如果第一个操作是volatile写，第二个操作是volatile读，那不能重排序。

举个例子，我们在案例中step 1，是普通变量的写，step 2是volatile变量的写，那符合第2个规则，这两个steps不能重排序。而step 3是volatile变量读，step 4是普通变量读，符合第1个规则，同样不能重排序。

但如果是下列情况：第一个操作是普通变量读，第二个操作是volatile变量读，那是可以重排序的：

// 声明变量
int a = 0; // 声明普通变量
volatile boolean flag = false; // 声明volatile变量// 以下两个变量的读操作是可以重排序的
int i = a; // 普通变量读
boolean j = flag; // volatile变量读

---

volatile的用途

基于volatile的内存语义，它在以下几个场景中非常有用：

1. 作为轻量级锁： volatile变量可以确保变量的内存可见性，因此在某些场景中可以替代锁，用于简单的状态标识。
2. 双重锁检查： 在实现单例模式时，使用volatile可以避免因重排序导致的未初始化实例问题。

以下是双重锁检查的示例代码：

public class Singleton {private static volatile Singleton instance; // 使用volatile关键字public static Singleton getInstance() {if (instance == null) { // 第7行synchronized (Singleton.class) {if (instance == null) {instance = new Singleton(); // 第10行}}}return instance;}
}

如果这里的变量声明不使用volatile关键字，是可能会发生错误的。它可能会被重排序：

instance = new Singleton(); // 第10行// 可以分解为以下三个步骤
1 memory=allocate();// 分配内存 相当于c的malloc
2 ctorInstanc(memory) //初始化对象
3 s=memory //设置s指向刚分配的地址// 上述三个步骤可能会被重排序为 1-3-2，也就是：
1 memory=allocate();// 分配内存 相当于c的malloc
3 s=memory //设置s指向刚分配的地址
2 ctorInstanc(memory) //初始化对象

而一旦假设发生了这样的重排序，比如线程A在第10行执行了步骤1和步骤3，但是步骤2还没有执行完。这个时候另一个线程B执行到了第7行，它会判定instance不为空，然后直接返回了一个未初始化完成的instance！

所以JSR-133对volatile做了增强后，volatile的禁止重排序功能还是非常有用的。

总结

volatile关键字通过确保内存可见性和禁止指令重排序，为Java并发编程提供了一个轻量级的同步机制。它在性能和功能之间提供了一个平衡：虽然不能像锁那样保证复杂的原子性操作，但在需要简洁、高效的内存同步时，volatile是一个非常有用的工具。

---

synchronized与锁

Synchronized关键字

synchronized 是Java中实现线程同步的重要关键字，用于锁定代码块或方法，从而确保同一时刻只有一个线程可以执行被锁定的代码。

synchronized的三种形式为：

1. 实例方法锁：锁定当前实例对象。

   public synchronized void instanceLock() {// 临界区
   }
   

2. 静态方法锁：锁定当前类的Class对象。

   public static synchronized void classLock() {// 临界区
   }
   

3. 代码块锁：锁定括号内指定的对象。

   public void blockLock() {Object obj = new Object();synchronized (obj) {// 临界区}
   }
   

---

所谓“临界区”，指的是某一块代码区域，它同一时刻只能由一个线程执行。在上面的例子中，如果synchronized关键字在方法上，那临界区就是整个方法内部。而如果是使用synchronized代码块，那临界区就指的是代码块内部的区域。

通过上面的例子我们可以看到，下面这两个写法其实是等价的作用：

// 关键字在实例方法上，锁为当前实例
public synchronized void instanceLock() {// code
}// 关键字在代码块上，锁为括号里面的对象
public void blockLock() {synchronized (this) {// code}
}

同理，下面这两个方法也应该是等价的：

// 关键字在静态方法上，锁为当前Class对象
public static synchronized void classLock() {// code
}// 关键字在代码块上，锁为括号里面的对象
public void blockLock() {synchronized (this.getClass()) {// code}
}

---

Java对象头

每个Java对象都有对象头。如果是非数组类型，则用2个字宽来存储对象头，如果是数组，则会用3个字宽来存储对象头。在32位处理器中，一个字宽是32位；在64位虚拟机中，一个字宽是64位。对象头的内容如下表：

长度	内容	说明
32/64bit	Mark Word	存储对象的hashCode或锁信息等
32/64bit	Class Metadata Address	存储到对象类型数据的指针
32/64bit	Array length	数组的长度（如果是数组）

我们主要来看看Mark Word的格式：

锁状态	29 bit 或 61 bit	1 bit 是否是偏向锁？	2 bit 锁标志位
无锁		0	01
偏向锁	线程ID	1	01
轻量级锁	指向栈中锁记录的指针	此时这一位不用于标识偏向锁	00
重量级锁	指向互斥量（重量级锁）的指针	此时这一位不用于标识偏向锁	10
GC标记		此时这一位不用于标识偏向锁	11

可以看到，当对象状态为偏向锁时，Mark Word存储的是偏向的线程ID；当状态为轻量级锁时，Mark Word存储的是指向线程栈中Lock Record的指针；当状态为重量级锁时，Mark Word为指向堆中的monitor对象的指针。

无锁、偏向锁、轻量级锁和重量级锁

Java 6 引入了新的锁机制来优化性能，锁的状态由低到高依次是：无锁、偏向锁、轻量级锁和重量级锁。

偏向锁

偏向锁是为了解决无竞争情况下的锁性能问题，它倾向于第一个获得锁的线程，避免了后续的CAS操作。偏向锁的撤销是较为消耗性能的过程，因此在竞争激烈时，偏向锁会被快速撤销。

Hotspot的作者经过以往的研究发现大多数情况下锁不仅不存在多线程竞争，而且总是由同一线程多次获得，于是引入了偏向锁。

偏向锁会偏向于第一个访问锁的线程，如果在接下来的运行过程中，该锁没有被其他的线程访问，则持有偏向锁的线程将永远不需要触发同步。也就是说，偏向锁在资源无竞争情况下消除了同步语句，连CAS操作都不做了，提高了程序的运行性能。

就是对锁置个变量，如果发现为true，代表资源无竞争，则无需再走各种加锁/解锁流程。如果为false，代表存在其他线程竞争资源，那么就会走后面的流程。

实现原理

一个线程在第一次进入同步块时，会在对象头和栈帧中的锁记录里存储锁的偏向的线程ID。当下次该线程进入这个同步块时，会去检查锁的Mark Word里面是不是放的自己的线程ID。

如果是，表明该线程已经获得了锁，以后该线程在进入和退出同步块时不需要花费CAS操作来加锁和解锁 ；如果不是，就代表有另一个线程来竞争这个偏向锁。这个时候会尝试使用CAS来替换Mark Word里面的线程ID为新线程的ID，这个时候要分两种情况：

• 成功，表示之前的线程不存在了， Mark Word里面的线程ID为新线程的ID，锁不会升级，仍然为偏向锁；
• 失败，表示之前的线程仍然存在，那么暂停之前的线程，设置偏向锁标识为0，并设置锁标志位为00，升级为轻量级锁，会按照轻量级锁的方式进行竞争锁。

CAS: Compare and Swap 比较并设置。用于在硬件层面上提供原子性操作。在 Intel 处理器中，比较并交换通过指令cmpxchg实现。 比较是否和给定的数值一致，如果一致则修改，不一致则不修改。

撤销偏向锁

偏向锁使用了一种等到竞争出现才释放锁的机制，所以当其他线程尝试竞争偏向锁时， 持有偏向锁的线程才会释放锁。

偏向锁升级成轻量级锁时，会暂停拥有偏向锁的线程，重置偏向锁标识，这个过程看起来容易，实则开销还是很大的，大概的过程如下：

1. 在一个安全点（在这个时间点上没有字节码正在执行）停止拥有锁的线程。
2. 遍历线程栈，如果存在锁记录的话，需要修复锁记录和Mark Word，使其变成无锁状态。
3. 唤醒被停止的线程，将当前锁升级成轻量级锁。

所以，如果应用程序里所有的锁通常处于竞争状态，那么偏向锁就会是一种累赘，对于这种情况，我们可以一开始就把偏向锁这个默认功能给关闭：

-XX:UseBiasedLocking=false。

---

轻量级锁

轻量级锁通过CAS操作来实现锁的获取和释放。如果竞争不激烈，线程可以避免阻塞；在自旋尝试失败后，锁会升级为重量级锁。

多个线程在不同时段获取同一把锁，即不存在锁竞争的情况，也就没有线程阻塞。针对这种情况，JVM采用轻量级锁来避免线程的阻塞与唤醒。

JVM会为每个线程在当前线程的栈帧中创建用于存储锁记录的空间，我们称为Displaced Mark Word。如果一个线程获得锁的时候发现是轻量级锁，会把锁的Mark Word复制到自己的Displaced Mark Word里面。

然后线程尝试用CAS将锁的Mark Word替换为指向锁记录的指针。如果成功，当前线程获得锁，如果失败，表示Mark Word已经被替换成了其他线程的锁记录，说明在与其它线程竞争锁，当前线程就尝试使用自旋来获取锁。

自旋：不断尝试去获取锁，一般用循环来实现。

自旋是需要消耗CPU的，如果一直获取不到锁的话，那该线程就一直处在自旋状态，白白浪费CPU资源。解决这个问题最简单的办法就是指定自旋的次数，例如让其循环10次，如果还没获取到锁就进入阻塞状态。

但是JDK采用了更聪明的方式——适应性自旋，简单来说就是线程如果自旋成功了，则下次自旋的次数会更多，如果自旋失败了，则自旋的次数就会减少。

自旋也不是一直进行下去的，如果自旋到一定程度（和JVM、操作系统相关），依然没有获取到锁，称为自旋失败，那么这个线程会阻塞。同时这个锁就会升级成重量级锁。

---

轻量级锁的释放：

在释放锁时，当前线程会使用CAS操作将Displaced Mark Word的内容复制回锁的Mark Word里面。如果没有发生竞争，那么这个复制的操作会成功。如果有其他线程因为自旋多次导致轻量级锁升级成了重量级锁，那么CAS操作会失败，此时会释放锁并唤醒被阻塞的线程。

---

重量级锁

重量级锁依赖操作系统的互斥量来实现线程同步，阻塞线程以避免CPU空转消耗。这种锁适用于长时间执行的同步代码块。

量级锁依赖于操作系统的互斥量（mutex） 实现的，而操作系统中线程间状态的转换需要相对比较长的时间，所以重量级锁效率很低，但被阻塞的线程不会消耗CPU。

前面说到，每一个对象都可以当做一个锁，当多个线程同时请求某个对象锁时，对象锁会设置几种状态用来区分请求的线程：

Contention List：所有请求锁的线程将被首先放置到该竞争队列
Entry List：Contention List中那些有资格成为候选人的线程被移到Entry List
Wait Set：那些调用wait方法被阻塞的线程被放置到Wait Set
OnDeck：任何时刻最多只能有一个线程正在竞争锁，该线程称为OnDeck
Owner：获得锁的线程称为Owner
!Owner：释放锁的线程

当一个线程尝试获得锁时，如果该锁已经被占用，则会将该线程封装成一个ObjectWaiter对象插入到Contention List的队列的队首，然后调用park函数挂起当前线程。

当线程释放锁时，会从Contention List或EntryList中挑选一个线程唤醒，被选中的线程叫做Heir presumptive即假定继承人，假定继承人被唤醒后会尝试获得锁，但synchronized是非公平的，所以假定继承人不一定能获得锁。这是因为对于重量级锁，线程先自旋尝试获得锁，这样做的目的是为了减少执行操作系统同步操作带来的开销。如果自旋不成功再进入等待队列。这对那些已经在等待队列中的线程来说，稍微显得不公平，还有一个不公平的地方是自旋线程可能会抢占了Ready线程的锁。

如果线程获得锁后调用Object.wait方法，则会将线程加入到WaitSet中，当被Object.notify唤醒后，会将线程从WaitSet移动到Contention List或EntryList中去。需要注意的是，当调用一个锁对象的wait或notify方法时，如当前锁的状态是偏向锁或轻量级锁则会先膨胀成重量级锁。

---

锁的升级流程

锁的升级通常从偏向锁开始，逐步升级到轻量级锁，最后是重量级锁。每次升级都是为了应对更复杂的线程竞争。

每一个线程在准备获取共享资源时：

• 第一步，检查MarkWord里面是不是放的自己的ThreadId ,如果是，表示当前线程是处于 “偏向锁” 。

• 第二步，如果MarkWord不是自己的ThreadId，锁升级，这时候，用CAS来执行切换，新的线程根据MarkWord里面现有的ThreadId，通知之前线程暂停，之前线程将Markword的内容置为空。

• 第三步，两个线程都把锁对象的HashCode复制到自己新建的用于存储锁的记录空间，接着开始通过CAS操作， 把锁对象的MarKword的内容修改为自己新建的记录空间的地址的方式竞争MarkWord。

• 第四步，第三步中成功执行CAS的获得资源，失败的则进入自旋 。

• 第五步，自旋的线程在自旋过程中，成功获得资源(即之前获的资源的线程执行完成并释放了共享资源)，则整个状态依然处于 轻量级锁的状态，如果自旋失败 。

• 第六步，进入重量级锁的状态，这个时候，自旋的线程进行阻塞，等待之前线程执行完成并唤醒自己。

---

各种锁的优缺点对比

锁	优点	缺点	适用场景
偏向锁	几乎没有加锁和解锁成本	在存在竞争时，撤销成本高	无竞争的同步块
轻量级锁	避免线程阻塞，提高响应速度	自旋失败时消耗CPU	短时间的无阻塞同步块
重量级锁	保证线程安全，避免CPU浪费	阻塞线程，降低响应速度	长时间的同步块，追求系统吞吐量

这篇关于J.U.C Review - volatile / synchronized / 锁 深入剖析的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！

---