Java内存屏障（Memory Barrier）与CPU乱序执行：保障并发可见性的底层机制

大家好，今天我们来深入探讨Java并发编程中一个至关重要的概念：内存屏障（Memory Barrier），以及它与CPU乱序执行之间的关系。理解这两个概念对于编写正确且高效的并发程序至关重要，尤其是在多核CPU架构下。

1. CPU乱序执行：性能优化的代价

现代CPU为了提高执行效率，往往会对指令进行乱序执行（Out-of-Order Execution）。这意味着CPU并不一定按照代码编写的顺序来执行指令，而是会根据指令之间的依赖关系以及硬件资源情况，进行优化调整，以最大化流水线的利用率。

举个简单的例子，假设我们有以下一段代码：

int a = 1;
int b = 2;
int c = a + b;

CPU可能会先计算b = 2，再计算a = 1，最后计算c = a + b。因为a = 1和b = 2这两条指令之间没有依赖关系，CPU可以并行执行它们。这种乱序执行在单线程环境下通常不会有问题，因为结果的正确性可以得到保证。但是，在多线程环境下，乱序执行可能会导致意想不到的问题，特别是涉及到共享变量的读写时。

考虑以下代码片段，有两个线程ThreadA和ThreadB：

// Thread A
int a = 0;
boolean flag = false;

public void write() {
    a = 1;
    flag = true;
}

// Thread B
public void read() {
    while (!flag) {
        // spin等待
    }
    System.out.println("a = " + a);
}

直观上，我们期望ThreadB能够打印出 "a = 1"。然而，由于CPU的乱序执行，以下情况可能会发生：

ThreadA先执行了flag = true，然后才执行a = 1。
ThreadB读取到flag为true，然后读取a的值，此时a的值可能仍然是0。

因此，ThreadB最终可能打印出 "a = 0"，这与我们的预期不符。这种由于乱序执行导致的并发问题，称为可见性问题。一个线程对共享变量的修改，其他线程可能无法及时看到。

2. Java内存模型（JMM）：并发编程的规范

为了解决并发环境下的可见性问题，Java定义了Java内存模型（Java Memory Model，JMM）。JMM并非实际存在的内存结构，而是一种抽象的概念，它定义了Java程序中各个变量的访问规则，以及多线程之间如何通过内存进行交互。

JMM的主要目标是：

定义共享变量的可见性、原子性和有序性。
屏蔽不同硬件和操作系统的内存访问差异，使Java程序可以在各种平台上正确运行。

JMM规定，所有的变量都存储在主内存中。每个线程都有自己的工作内存，工作内存中保存了该线程使用到的变量的主内存副本。线程对变量的所有操作（读取、赋值等）都必须在工作内存中进行，而不能直接读写主内存中的变量。线程之间无法直接访问对方工作内存中的变量，线程间的通信必须通过主内存来完成。

可以把JMM想象成这样：

+-----------------+
|    Main Memory   |
+-----------------+
       ^   |   ^
       |   |   |
       |   |   |
+-----------------+   +-----------------+
| Thread A        |   | Thread B        |
| Working Memory  |   | Working Memory  |
+-----------------+   +-----------------+

JMM定义了happens-before原则，它描述了两个操作之间的可见性关系。如果一个操作happens-before另一个操作，那么前一个操作的结果对于后一个操作是可见的。

Happens-before原则是JMM中最重要的概念之一，它有很多规则，例如：

程序顺序规则： 在一个线程中，按照程序代码的执行顺序，排在前面的操作happens-before排在后面的操作。
监视器锁规则： 对一个锁的解锁happens-before后续对这个锁的加锁。
volatile变量规则： 对一个volatile变量的写操作happens-before后续对这个volatile变量的读操作。
传递性： 如果A happens-before B，且B happens-before C，那么A happens-before C。

这些happens-before规则保证了在特定的情况下，线程之间的可见性。

3. 内存屏障（Memory Barrier）：强制内存顺序

内存屏障（Memory Barrier），也称为内存栅栏（Memory Fence），是一种CPU指令，用于强制CPU对内存访问的顺序进行约束。它可以阻止CPU的乱序执行，保证特定的内存访问顺序。

内存屏障可以分为以下几种类型：

Load Barrier (读屏障)： 在读指令之前插入，强制CPU先完成Load Barrier之前的读操作，再执行Load Barrier之后的读操作。
Store Barrier (写屏障)： 在写指令之后插入，强制CPU先完成Store Barrier之前的写操作，再执行Store Barrier之后的写操作。
Full Barrier (全屏障)： 既能阻止读操作的重排序，也能阻止写操作的重排序。它是一种最强的内存屏障，会强制CPU执行所有未完成的内存操作。

不同类型的内存屏障对性能的影响不同，Full Barrier的开销最大，Load Barrier和Store Barrier的开销相对较小。

4. Java中的内存屏障：volatile和synchronized

Java通过volatile关键字和synchronized关键字来提供内存屏障的功能，从而保证并发程序的可见性和有序性。

volatile:
- 保证了被volatile修饰的变量的可见性：当一个线程修改了volatile变量的值，新值会立即同步到主内存，其他线程可以立即看到这个修改。
- 禁止指令重排序优化：volatile变量的读写操作不会被重排序，保证了代码的执行顺序。
volatile的实现原理是，在对volatile变量进行读写操作时，会在指令序列中插入内存屏障。具体来说：
- 在每个volatile写操作的前面插入StoreStore屏障，在后面插入StoreLoad屏障。
- 在每个volatile读操作的后面插入LoadLoad屏障和LoadStore屏障。
这些内存屏障保证了volatile变量的读写操作的原子性和可见性。

回到之前的例子，如果我们将flag变量声明为volatile：
```
// Thread A
int a = 0;
volatile boolean flag = false;

public void write() {
    a = 1;
    flag = true;
}

// Thread B
public void read() {
    while (!flag) {
        // spin等待
    }
    System.out.println("a = " + a);
}
```
那么，ThreadB就一定能打印出 "a = 1"。因为flag变量的写操作happens-before flag变量的读操作，保证了ThreadA对flag的修改对ThreadB是可见的。

需要注意的是，volatile只能保证可见性和有序性，不能保证原子性。对于复合操作（例如i++），仍然需要使用锁来保证原子性。
synchronized:
- synchronized关键字可以用来修饰方法或者代码块，保证了在同一时刻只有一个线程可以执行被synchronized修饰的代码。
- synchronized不仅保证了原子性，也保证了可见性。当一个线程释放锁时，会将工作内存中的共享变量刷新到主内存中；当一个线程获取锁时，会从主内存中读取共享变量的最新值。
synchronized的实现原理是，在进入synchronized代码块之前，会执行monitorenter指令，获取锁；在退出synchronized代码块之后，会执行monitorexit指令，释放锁。

monitorenter指令相当于Load Barrier，它会强制线程从主内存中读取共享变量的最新值。 monitorexit指令相当于Store Barrier，它会强制线程将工作内存中的共享变量刷新到主内存中。

因此，synchronized可以保证线程之间的可见性。

5. 内存屏障的底层实现：汇编指令

内存屏障最终会转化为CPU的汇编指令。不同的CPU架构提供了不同的内存屏障指令。

例如，在x86架构下，可以使用mfence指令来实现Full Barrier。 lfence指令实现Load Barrier，sfence指令实现Store Barrier。

在ARM架构下，可以使用dmb (Data Memory Barrier) 指令来实现内存屏障。 dmb指令有很多变体，例如dmb sy，dmb ish等，分别对应不同的内存屏障强度。

Java虚拟机（JVM）会根据不同的CPU架构，将volatile和synchronized关键字转化为相应的内存屏障指令。

6. 内存屏障的应用场景

内存屏障在并发编程中有很多应用场景，例如：

双重检查锁（Double-Checked Locking）： 双重检查锁是一种常用的单例模式实现方式。为了保证线程安全，需要使用volatile关键字来修饰单例对象，防止指令重排序导致的问题。
```
public class Singleton {
    private volatile static Singleton instance;

    private Singleton() {}

    public static Singleton getInstance() {
        if (instance == null) {
            synchronized (Singleton.class) {
                if (instance == null) {
                    instance = new Singleton();
                }
            }
        }
        return instance;
    }
}
```
如果没有volatile关键字，以下情况可能会发生：
1. ThreadA执行instance = new Singleton()，这行代码实际上可以分为三个步骤：
  - 分配内存空间
  - 初始化Singleton对象
  - 将instance指向分配的内存地址
2. 由于指令重排序，CPU可能会先执行第1步和第3步，然后才执行第2步。
3. 此时，ThreadB执行getInstance()方法，发现instance不为null，直接返回instance。
4. 但是，此时instance指向的内存空间还没有完成初始化，ThreadB可能会使用到未初始化的对象，导致程序出错。
使用volatile关键字可以防止指令重排序，保证Singleton对象在初始化完成之后，才能被其他线程访问。
并发队列： 在实现并发队列时，需要使用内存屏障来保证队列的线程安全。例如，在Disruptor框架中，使用了大量的内存屏障来提高并发性能。
原子类： java.util.concurrent.atomic包中的原子类，例如AtomicInteger、AtomicLong等，底层也是通过内存屏障来保证原子性。

7. 性能考量：权衡可见性和性能

内存屏障虽然可以保证并发程序的正确性，但是也会带来一定的性能开销。因此，在使用内存屏障时，需要权衡可见性和性能。

过度使用内存屏障会降低程序的性能。
在不需要保证可见性的情况下，可以避免使用内存屏障。
选择合适的内存屏障类型，例如使用volatile代替synchronized，可以提高程序的性能。

以下表格总结了volatile和synchronized的区别：

特性	volatile	synchronized
可见性	保证	保证
原子性	不保证（只能保证单个变量的读写原子性）	保证
有序性	保证，禁止指令重排序	保证，通过互斥锁实现
锁机制	无锁	互斥锁
适用场景	只有一个线程写，多个线程读的场景	需要保证原子性操作的场景
性能	性能通常比synchronized好	性能通常比volatile差

8. 总结：深入理解并发底层机制

今天我们深入探讨了Java内存屏障与CPU乱序执行之间的关系。内存屏障是解决并发可见性问题的关键技术，Java通过volatile和synchronized关键字提供了内存屏障的功能。理解内存屏障的原理，可以帮助我们编写更正确且高效的并发程序。掌握volatile和synchronized的使用场景，能够在实际开发中做出更好的选择，避免过度使用内存屏障，从而提升程序性能。

Java内存屏障（Memory Barrier）与CPU乱序执行：保障并发可见性的底层机制

发表回复 取消回复

发表回复取消回复