六、volatile、锁、final 的内存语义

1、volatile 的内存语义

1.1、volatile 的特性

这里可以把对 volatile 变量的单个读/写，看成是使用同一个锁对普通变量的单个读/写操作做了同步。

1.1.1、示例代码

volatile 示例代码

package com.yj.volatile_;
/**
 * @description: volatile 的使用
 * @author: erlang
 * @since: 2021-01-14 21:56
 */
public class VolatileExample {
    /**
     * 使用 volatile 声明变量
     */
    private volatile long value = 0L;
    public long getValue() {
        // 单个 volatile 变量的读
        return value;
    }
    public void setValue(long value) {
        // 单个 volatile 变量的写
        this.value = value;
    }
    public void getAndIncrement() {
        // 复合 volatile 变量的读/写
        this.value++;
    }
}

使用 synchronized 实现 volatile 语义

package com.yj.volatile_;
/**
 * @description: synchronized 实现 volatile
 * @author: erlang
 * @since: 2021-01-14 22:02
 */
public class VolatileSyncExample {
    /**
     * 普通变量
     */
    private long value = 0L;
    /**
     * 对单个读加锁
     */
    public synchronized long getValue() {
        return value;
    }
    /**
     * 对单个写加锁
     */
    public synchronized void setValue(long value) {
        this.value = value;
    }
    /**
     * 普通方法的调用
     */
    public void getAndIncrement() {
        // 调用同步的读方法
        long value = getValue();
        // 普通写操作
        value++;
        // 调用同步的写方法
        setValue(value);
    }
}

上面两个实例代码可以知道，一个 volatile 变量的单个读/写操作，与一个普通变量的读/写操作都是使用同一个锁来同步，它们之间的执行效果相同。

1.1.2、volatile 变量具有的特性

1. 锁的 Happens-Before 规则保证释放锁和获取锁的两个线程之间的内存可见性。任何一个线程对 volatile 变量的读，总是能到看其他线程对这个变量最后的写操作。
2. 锁的语义决定了临界区代码的执行具有原子性。即使是 64 位的 long 和 double 类型变量，只要它是 volatile 变量，对该变量的读/写就具有原子性。但是如果是多个 volatile 的操作（volatile++ 的复合操作），是不具有原子性的

1.2、volatile 与 Happens-Before

从 JSR-133 开始（JDK5 开始），volatile 变量的写-读可以实现线程之间的通信。从内存语义的角度来说，volatile 的写-读与锁的释放-获取有相同的效果。

1. volatile 写和锁的释放有相同的内存语义
2. volatile 读和锁的获取有相同的内存语义

示例代码如下：

package com.yj.order;
/**
 * @description: happens before demo
 * @author: erlang
 * @since: 2021-01-10 22:54
 */
public class TestHappensBefore {
    int x = 0;
    volatile boolean v = false;
    public void writer() {
        x = 1; // 1
        v = true; // 2
    }
    public void reader() {
        if (v) { // 3
            // 这里x会是多少呢？
            System.out.println("reader: x=" + x); // 4
        }
    }
}

假设线程 A 执行 writer 方法之后，线程 B 执行 reader 方法。根据 Happens-Before 规则，过程如下：

1. 根据程序次序规则，1 Happens-Before 2，3 Happens-Before 4
2. 根据 volatile 规则，2 Happens-Before 3
3. 根据 Happens-Before 的传递性规则，1 Happens-Before 4

Happens-Before 关系图如下：

这里线程 A 对 v 的写入，在线程 B 读取 v 的时候，是立即可见的。

1.3、volatile 写-读的内存语义

1.3.1、volatile 写的内存语义

当写一个 volatile 变量时，JMM 会把该线程对应的本地内存中的共享变量值帅拿到主内存。

1.3.2、volatile 读的内存语义

当读一个 volatile 变量时，JMM 会把线程对应的本地内存置为无效。线程接下来将从主内存中读取共享变量

1.3.3 volatile 内存语义的总结

1. 线程 A 写一个 volatile 变量，实质上是线程 A 向接下来将要读这个 volatile 变量的某个线程发出（其对共享变量所做修改的）消息
2. 线程 B 读一个 volatile 变量，实质上是线程 B 接收了之前某个线程发出的（1 发出的消息）消息
3. 线程 A 写一个 volatile 变量，随后线程 B 读这个 volatile 变量，这个过程实质上是线程 A 通过主内存向线程 B 发送消息

1.4 volatile 内存语义的实现

JMM 对编译器制定的 volatile 重排序规则，如表：

从表中可知，在程序中

1 当第二个操作是 volatile 写时，不管第一个操作是什么，都不能重排序。这个规则确保 volatile 写之前的操作不会被编译器重排序到 volatile 写之后。
2. 当第一个操作是 volatile 读时，不管第二个操作是什么，都不能重排序。这个规则确保 volatile 读之后的操作不会被编译器重排序到 volatile 读之前。
3. 当第一个操作是 volatile 写，第二个操作是 volatile 读时，不能重排序。

为了实现 volatile 的内存语义，编译器在生成字节码时，会在指令序列中插入内存屏障来禁止特定类型的处理器重排序。对于编译器来说，发现一个最优布置来最小化插入屏障的总数几乎不可能。为此，JMM 采取保守策略，下面是基于保守策略的 JMM 内存屏障插入策略

1. 在每个 volatile 写操作的前面插入一个 StoreStore 屏障
2. 在每个 volatile 写操作的后面插入一个 StoreLoad 屏障
3. 在每个 volatile 读操作的后面插入一个 LoadLoad 屏障
4. 在每个 volatile 读操作的后面插入一个 LoadStore 屏障

上述内存屏障插入策略非常保守，但它可以保证在任意处理器平台，任意程序中都能得到正确的 volatile 内存语义。

下面是对 volatile 写插入内存屏障后生成的指令序列示意图

StoreStore 屏障可以保证在 volatile 写之前，其前面的所有普通写操作已经对任意处理器可见了。这是因为 StoreStore 屏障将保证上面所有的普通写在 volatile 写之前刷新都主内存。

StoreLoad 屏障的作用是避免 volatile 写与后面可能有的 volatile 读/写操作重排序。因为编译器常常无法准确判断在一个 volatile 的后面是否需要插入一个 StoreLoad 屏障（比如，一个 volatile 写之后立即 return）。

为了保证能正确实现 volatile 的内存语义，JMM 在采取了保守策略：在每个 volatile 写的后面或者读的前面插入一个 StoreLoad 屏障。因为 volatile 写-读内存语义的常见模式是：一个写线程写 volatile 变量，多个读线程读同一个 volatile 变量。从整体执行效率的角度考虑，JMM 最终选择了在每个 volatile 写的后面插入一个 StoreLoad 屏障。从这里可以看到 JMM 在实现上的一个特点：首先保证正确性，然后在去追求执行效率。

下面是对 volatile 读插入内存屏障后生成的指令序列示意图

• LoadLoad 屏障用来禁止处理器把上面的 volatile 读与下面的普通读重排序。
• LoadStore 屏障用来禁止处理器把上面的 volatile 读与下面的普通写重排序。

上述 volatile 写和 volatile 读的内存屏障插入策略非常保守。在实际执行时，只要不改变 volatile 写-读内存语义，编译器可以跟徐具体情况省略不必要的屏障。

package com.yj.volatile_;
/**
 * @description: volatile 内存屏障
 * @author: erlang
 * @since: 2021-01-15 00:09
 */
public class VolatileBarrierExample {
    private int x = 0;
    private volatile int y = 1;
    private volatile int z = 2;
    public void readAndWrite() {
        // 第一 volatile 读
        int i = y;
        // 第二个 volatile 读
        int j = z;
        // 第一个普通写
        x = i + j;
        // 第一个 volatile 写
        y = i + 1;
        // 第二个 volatile 写
        z = i + 1;
    }
}

JMM 针对 readAndWrite 方法，编译器在生成字节码时可以做如下优化

这里最后的 StoreLoad 屏障不能省略，主要是因为第二个 volatile 写之后，方法立即 return。此时编译器无法确认后面是否会有 volatile 读/写操作，采取了保守策略，在这里插入一个 StoreLoad 屏障。

上面的优化针对任意处理器平台，由于不同的处理器有不同松紧度的处理器内存模型，内存屏障的插入还可以根据具体的处理器内存模型继续优化。以 X86 处理器为例，上图中除最后的 StoreLoad 屏障外，其他的屏障都会省略。

前面保守策略下的 volatile 读和写，在 X86 处理器平台可以优化如图所示

X86 处理器仅会对写-读操作做重排序，不会丢读-读、读-写和写-写操作做重排序，因此会省略这三种操作类型对应的内存屏障。在 x86 中，JMM 仅需在 volatile 写后面插入一个 StoreLoad 屏障即可正确实现 volatile 写-读的内存语义。从上面可知，x86 中 volatile 写的开销比读的开销大会多。

1.5、JSR-133 为什么增强 volatile 内存语义

在 JSR-133 之前的旧 Java 内存模型中，虽然不允许 volatile 变量之前重排序，但旧的 Java 内存模型允许 volatile 变量与普通变量重排序。在旧的内存模型中，示例代码 VolatileBarrierExample 的程序可能被重排序成下列时序来执行。

在旧的内存模型中，当操作 1 和 2 之间没有数据依赖关系时，1 和 2 之间就能被重排序（3 和 4 类似）。其结果就是，线程 B 执行 操作时，不一定能看到线程 A 在执行操作 1 时对共享变量的修改值。

因此，在旧的内存模型中，volatile 的写-读不具有锁的释放-获取的内存语义。为了提供一种比锁更轻量级的线程之间通信的机制，JSR-133 决定增强 volatile 的内存语义：严格限制编译器和处理器对 volatile 变量与普通变量的重排序，确保 volatile 的写-读和锁的释放-获取具有相同的内存语义。这里只要 volatile 变量与普通变量之间的重排序，可能会破坏 volatile 的内存语义，就会被编译器重排序规则和处理器内存屏障插入策略禁止

由于 volatile 仅仅保证对单个 volatile 变量的读/写具有原子性，而锁的互斥执行的特性可以确保对整个临界区代码的执行具有原子性。在功能上，锁比 volatile 更强大；在可伸缩性和执行性能上，volatile 更具有优势。

2、锁的内存语义

2.1、锁的释放-获取与 Happens-Before

锁是 Java 并发编程中最重要的同步机制，锁除了让临界区互斥执行外，还可以让释放锁的线程向获取同一个锁的线程发送消息。

package com.yj.sync;
import com.yj.jmm.CacheLineNonPadding;
/**
 * @description: 锁获取-释放
 * @author: erlang
 * @since: 2021-01-16 00:57
 */
public class MonitorExample {
    int x = 0;
    public synchronized void write() { // 1
        x++; // 2
    } // 3
    public synchronized int read() { // 4
        return x; // 5
    } // 6
    public static void main(String[] args) throws InterruptedException {
        MonitorExample monitor = new MonitorExample();
        Thread threadA = new Thread(() -> {
            monitor.write();
        });
        Thread threadB = new Thread(() -> {
            threadA.start();
            try {
                // 这里保证 线程 A 必须执行
                Thread.sleep(100);
            } catch (InterruptedException e) {
                e.printStackTrace();
            }
            System.out.println("result: " + monitor.read());
        });
        threadB.start();
    }
}

假设线程 A 执行 write 方法，随后线程执行 B 执行 reader 方法。根据 Happens-Before 规则：

根据程序次序规则，操作 1 Happens-Before 2、2 Happens-Before 3，4 Happens-Before 5、5 Happens-Before 6
根据监视器锁规则，3 Happens-Before 4
根据 Happens-Before 的传递性，2 Happens-Before 5

如图，线程 A 释放了锁之后，随后线程 B 获取同一个锁。在上图中，2 Happens-Before 5。因此，线程 A 在释放锁之前所有可见的共享变量，在线程 B 获取同一个锁之后，将立即对线程 B 可见。

2.2、锁的获取和释放的内存语义

当线程释放锁时，JMM 会把线程对应的本地内存中的共享变量刷新到主内存。以 MonitorExample 程序为例，线程 A 释放锁后，共享数据的状态示意图

当线程 B 获取锁时，JMM 会把该线程对应的本地内存置为无效。从而使得被监视器保护的临界区代码必须从主内存中读取共享变量。如图所示：

对比锁释放-获取的内存语义与 volatile 写-读的内存语义可以看出，锁释放与 volatile 写有相同的内存语义，所获取和 volatile 读有相同的内存语义。综上，锁释放-获取的内存语义：

1. 线程 A 释放一个锁，实质上是线程 A 向接下来将要获取这个锁的某个线程发出（线程 A 对共享变量所做修改的）消息
2. 线程 B 获取一个锁，实质上是线程 B 接收了之前某个线程发出的（在释放锁锁之前对共享变量所做修改的）消息
3. 线程 A 释放锁，随后线程 B 获取这个锁，这个过程实质上是线程 A 通过主内存向线程 B 发送消息

2.3、锁内存语义的实现

这里将借助 ReentrantLock 的源码，来分析内存语义的具体实现机制。在 ReentrantLock 中，调用 lock 方法获取锁，调用 unlock 方法释放锁，示例代码：

package com.yj.lock;
import java.util.concurrent.locks.ReentrantLock;
/**
 * @description: ReentrantLock 分析
 * @author: erlang
 * @since: 2021-01-19 22:27
 */
public class ReentrantLockExample {
    int value = 0;
    ReentrantLock lock = new ReentrantLock();
    public void writer() {
        lock.lock(); // 获取锁
        try {
            value++;
        } finally {
            lock.unlock(); // 释放锁
        }
    }
    public void reader() {
        lock.lock(); // 获取锁
        try {
            int value = this.value;
            System.out.println(value);
        } finally {
            lock.unlock(); // 释放锁
        }
    }
}

ReentrantLock 的实现依赖于 Java 同步器框架 AbstractQueuedSynchronizer（AQS）。AQS 使用一个整型的 volatile 变量（state）来维护同步状态，这个 volatile 变量是 ReentrantLock 内存语义实现的关键。

2.3.1、ReentrantLock 的公平锁

ReentrantLock 分为公平锁和非公平锁，首先先看下公平锁，使用公平锁时，加锁方法 lock 调用轨迹如下

其中第四步真正开始加锁，代码如下

/**
 * Fair version of tryAcquire.  Don't grant access unless
 * recursive call or no waiters or is first.
 */
protected final boolean tryAcquire(int acquires) {
    final Thread current = Thread.currentThread();
    // 获取锁前，首先读 volatile 变量 state
    int c = getState();
    if (c == 0) {
        if (!hasQueuedPredecessors() &&
            compareAndSetState(0, acquires)) {
            setExclusiveOwnerThread(current);
            return true;
        }
    }
    else if (current == getExclusiveOwnerThread()) {
        int nextc = c + acquires;
        if (nextc < 0)
            throw new Error("Maximum lock count exceeded");
        setState(nextc);
        return true;
    }
    return false;
}

从源码中可以看出，加锁时首先读 volatile 变量 state。在使用公平锁时，解锁方法 unlock 调用轨迹如下

在第三步真正开始释放锁，源代码如下：

 protected final boolean tryRelease(int releases) {
    int c = getState() - releases;
    if (Thread.currentThread() != getExclusiveOwnerThread())
        throw new IllegalMonitorStateException();
    boolean free = false;
    if (c == 0) {
        free = true;
        setExclusiveOwnerThread(null);
    }
    // 释放锁后，更新 volatile 变量 state
    setState(c);
    return free;
}

从上面的源代码可以看出，在释放锁后写 volatile 变量 state。

公平锁在释放锁后，写 volatile 变量 state；在获取锁时，首先读这个 volatile 变量。根据 volatile 的 Happens-Before 规则：

1. 顺序性规则：对于线程 A，value++; Happens-Before 释放锁的操作 unlock()；
2. volatile 变量规则：由于 state = 1 会先读取 state，所以线程 A 的 unlock() 操作 Happens-Before 线程 B 的 lock() 操作；
3. 传递性规则：线程 A 的 value++ Happens-Before 线程 B 的 lock() 操作。

所以说，后续线程 B 能够看到 value 的正确结果。

2.3.1、ReentrantLock 的非公平锁

非公平锁的内存语义的实现，非公平锁的释放和公平锁的完全一样，所以这里仅仅分析给公平锁额获取。使用非公平锁时，加锁方法 lock 调用轨迹如下

第三步真正开始加锁，下面是该方法的源代码

 /**
 * Atomically sets synchronization state to the given updated
 * value if the current state value equals the expected value.
 * This operation has memory semantics of a {@code volatile} read
 * and write.
 *
 * @param expect the expected value
 * @param update the new value
 * @return {@code true} if successful. False return indicates that the actual
 *         value was not equal to the expected value.
 */
protected final boolean compareAndSetState(int expect, int update) {
    // See below for intrinsics setup to support this
    return unsafe.compareAndSwapInt(this, stateOffset, expect, update);
}

该方法以原子操作的方式更新 state 变量，其实 compareAndSet 方法就是我们常说的 CAS。JDK 文档对该方法的说明是，如果当前状态值等于预期值，则以原子方式将同步状态设置为给定的更新值。此操作具有 volatile 读和 volatile 写的内存语义。

前面说过，编译器不会对 volatile 读与 volatile 读后面的任意内存操作重排序；也不会对 volatile 写与 volatile 写前面的任意内存操作重排序。组合这两个条件，意味着为了同时实现 volatile 读和 volatile 写的内存语义，编译器不能对 CAS 与 CAS 前面和后面的任意内存操作重排序。

这里以 X86 处理器说明，CAS 是如何同时具有 volatile 读和写的内存语义的。下面是 sun.misc.Unsafe 类的 compareAndSwapInt 方法的源码：

public final native boolean compareAndSwapInt(Object var1, long var2, int var4, int var5);

可以看到，这是一个本地方法调用。这个本地方法在 openjdk 中，一次调用 c++ 代码为：unsafe.cpp、atomic.cpp 和 atomic_linux_x86.inline.hpp。下面是 atomic_linux_x86.inline.hpp 代码片段：

inline jint     Atomic::cmpxchg    (jint     exchange_value, volatile jint*     dest, jint     compare_value) {
  int mp = os::is_MP();
  __asm__ volatile (LOCK_IF_MP(%4) "cmpxchgl %1,(%3)"
                    : "=a" (exchange_value)
                    : "r" (exchange_value), "a" (compare_value), "r" (dest), "r" (mp)
                    : "cc", "memory");
  return exchange_value;
}

从代码中可以看出，程序会根据当前处理器的类型来决定是否为 cmpxchg 指令添加 lock 前缀。如果程序是在多处理器上运行，就为 cmpxchg 指令加上 lock 前缀（lock cmpxchg）；如果程序是在单处理器上运行时，就省略 lock 前缀（单处理器自身会维护单处理内的顺序一致性，不需要 lock 前缀提供的内存屏障效果）。

Intel 的手册对 lock 前缀的说明如下

1. 确保内存的读-改-写操作原子执行。在 Pentium 及 Pentium 之前的处理器中，带有 lock 前缀的指令在执行期间会锁住总线，使得其他处理器暂时无法通过总线访问内存。这会地带来昂贵的开销。从 Pentium4、Intel Xeon 及 P6 处理器开始，Intel 使用缓存锁定（Cache Locking）来保证指令执行的原子性。缓存锁定将大大降低 lock 前缀指令的执行开销。
2. 禁止该指令，与之前和之后的读和写指令重排序
3. 把写缓冲区中的所有数据刷新到内存中

上面的第 2 点和第 3 点所具有的内存屏障效果，足以同时实现 volatile 读和 volatile 写的内存语义。经过上面的分析，现在可以知道为什么 JDK 文档说 CAS 同时具有 volatile 读和 volatile 写的内存予以了。

这里对公平锁和非公平锁的内存语义做个总结：

1. 公平锁和非公平锁释放时，最后都要写一个 volatile 变量 state
2. 公平锁获取时，首先会去读 volatile 变量
3. 非公平锁获取时，首先会用 CAS 更新 volatile 变量，这个操作同时具有 volatile 读和 volatile 写的内存语义

从 ReentrantLock 的分析可以看出，锁释放-获取的内存语义的实现至少有下面两种方式：

1. 利用 volatile 变量的写-读所具有的内存语义
2. 利用 CAS 锁附带的 volatile 读和 volatile 写的内存语义

2.4、concurrent 包的实现

由于 Java 的 CAS 同时具有 volatile 读和 volatile 写的内存语义，因此 Java 线程之间的通信现在有了下面 4 种方式。

1. A 线程写 volatile 变量，随后 B 线程读这个 volatile 变量
2. A 线程写 volatile 变量，随后 B 线程用 CAS 更新这个 volatile 变量
3. A 线程用 CAS 更新一个 volatile 变量，随后 B 线程用 CAS 更新这个 volatile 变量
4. A 线程用 CAS 更新一个 volatile 变量，随后 B 线程读这个 volatile 变量

Java 的 CAS 会使用现代处理器上提供的高效机器级别的原子指令，这些原子指令以原子方式对内存执行读-改-写操作，这是在多处理器中实现同步的关键。从本质上来说，能够支持原子性操作读-改-写指令的计算机，是顺序计算图灵机的异步等价机器，因此现代的多处理器都会去支持某种能对内存执行原子性读-改-写操作的原子指令。同时 volatile 变量的读/写和 CAS 可以实现线程之间的通信。把这些特性整合在一起，就形成了整个 concurrent 包得以实现的基石。concurrent 包下有一个通用化的实现模式：

1. 声明共享变量为 volatile
2. 使用 CAS 的原子条件更新来实现线程之间的同步
3. 配合以 volatile 的读/写和 CAS 所具有的 volatile 读和写的内存语义来实现线程之间的通信

AQS，非阻塞数据结构和原子变量类（java.util.concurrent.atomic 包中的类），这些 concurrent 包中的基础类都是使用这种模式来实现的，而 concurrent 包中的高层类又是依赖于这些基础类来实现的。从整体上看，concurrent 包的实现示意图如下：

3、final 的内存语义

3.1、final 的重排序规则

对于 final，编译器和处理器会遵守两个重排序规则

1. 在构造函数内对一个 final 变量的写入，与随后把这个构造对象的引用赋值给一个引用变量，这两个操作不能重排序
2. 首次读一个包含 final 变量的对象的引用，与随后首次读这个 final 变量，这两个操作之间不能重排序。

示例代码如下，代码中，线程 A 先执行 writer 方法，线程 B 后执行 reader 方法

package com.yj.final_;
/**
 * @description: final 关键字
 * @author: erlang
 * @since: 2021-01-16 18:34
 */
public class FinalExample {
    int i;
    final int j;
    static FinalExample obj;
    public FinalExample() {
        // 写普通变量
        this.i = 1;
        // 写 final 变量
        this.j = 2;
    }
    public static void writer() {
        obj = new FinalExample();
    }
    public static void reader() {
        // 读对象引用
        FinalExample example = obj;
        if (example.i == 0) {
            // 对普通变量
            System.out.println("example.i=" + example.i);
            // 读 final 变量
            System.out.println("example.j=" + example.j);
        }
    }
    public static void main(String[] args) {
        for (int i = 0; i < 1000_0000; i++) {
            Thread threadB = new Thread(() -> {
                FinalExample.reader();
            });
            Thread threadA = new Thread(() -> {
                FinalExample.writer();
                threadB.start();
            });
            threadA.start();
        }
    }
}

3.2、写 final 变量的重排序规则

写 final 变量的重排序规则，禁止把 final 变量的写重排序到构造函数之外。这个规则的实现包含下面两个方面

1. JMM 禁止编译器把 final 变量的写重排序到构造函数之外
2. 编译器会在 final 变量的写之后，构造函数 return 之前，插入一个 StoreStore 屏障。这个屏障禁止处理器把 final 变量的写操作重排序到构造函数之外

其中 FinalExample 示例中的 writer 方法只包含一行代码：obj = new FinalExample();，这行代码包含两个步骤：

1. 构造一个 FinalExample 类型的对象
2. 把这个对象的引用赋值给引用变量 obj

假设线程 B 读对象引用和读对象的成员变量之间没有重排序，可能的执行顺序如图：

从上图可知，写普通变量的操作被编译器重排序到构造函数之外，线程 B 错误地读取了普通变量 i 初始化之前的值。而写 final 变量的重排序规则可以确保，在对象引用为任意线程可见之前，对象的 final 变量已经被初始化完成，而普通变量不具有这个保障。线程 B 看到对象引用 obj 时，很可能 obj 对象还没有构造完成。

3.3、读 final 变量的重排序

读 final 变量的重排序规则是，在一个线程中，初次读对象引用与初次读该对象的 final 成员变量，JMM 禁止处理器重排序这两个操作（这个规则仅仅针对处理器）。编译器会在读 final 变量操作的前面插入一个 LoadLoad 屏障。

首次读对象引用与首次读该对象的 final 成员变量，这两个操作存在之间依赖关系。由于编译器遵守间接依赖关系，因此编译器不会重排序这两个操作。大多数处理器也会遵守间接依赖，也不会重排序这两个操作。但有少数处理器允许对存在间接依赖关系的操作做重排序（比如 alpha 处理器），这个规则就是专门针对这种处理器。

FinalExample 示例中的 reader 方法包含三个操作

1. 读引用变量 obj
2. 读对象的普通变量 i
3. 读对象的 final 变量 j

假设线程 A 没有发生重排序，同时程序在不遵守间接依赖的处理器上执行时，可能的执行顺序如图：

从上图可知，读对象的普通变量的操作被处理器重排序得到读对象引用之前，读普通变量时，该变量还没有被线程 A 写入。而读 final 变量的重排序规则会把读 final 变量的操作限定在读对象引用之后，此时该 final 变量已经被线程 A 初始化完成。

读 final 变量的重排序规则可以确保，在读一个对象的final 变量之前，一定会先读包含这个 final 变量的对象的引用。在这个示例程序中，如果该引用不为 null，那么引用对象的 final 变量一定已经被线程 A 初始化过了。

3.4、final 变量为引用类型

示例代码如下，示例中的 final 变量 array[] 是引用类型，它引用一个 int[]。对于引用类型，写 final 变量的重排序规则对编译器和处理器增加了如下约束：在构造函数内对一个 final 引用的对象的成员变量的写入，与随后在构造函数外把对象的引用赋值给一个引用变量，这两个操作之间不能重排序。

package com.yj.final_;
/**
 * @description: final 引用类型
 * @author: erlang
 * @since: 2021-01-19 21:05
 */
public class FinalReferenceExample {
    private final int[] array;
    private static FinalReferenceExample obj;
    public FinalReferenceExample() {
        this.array = new int[1]; // 1
        array[0] = 1; // 2
    }
    public static void writerOne() {
        obj = new FinalReferenceExample(); // 3
    }
    public static void writerTwo() {
        obj.array[0] = 2; // 4
    }
    public static void reader() {
        if (obj != null) { // 5
            int value = obj.array[0]; // 6
        }
    }
}

对上面的实例程序，假设首先线程 A 执行 writerOne 方法，执行完后线程 B 执行 writerTwo 方法，执行完成后线程 C 执行 reader 方法。可能的线程执行顺序如图所示，1 是对 array 的写入，2 是对 array[] 元素的写入，3 是把被构造的对象的引用赋值给 obj。上面的代码中 1 不能和 3 重排序，2 和不能和 3 重排序。

JMM 可以确保线程 C 至少能看到线程 A 在构造函数中对 arrya[] 元素的写入。即至少能看到 array[0] 的值为 1。而线程 B 对数组元素的写入，线程 C 可能看到也可能看不到。JMM 不保证线程 B 的写入对线程 C 可见，因为线程 B 和线程 C 之间存在数据竞争，此时的执行结果不可预知。

3.5、为什么 final 引用不能从构造函数内逃逸

写 final 变量的重排序规则确保：在引用变量为任意线程可见之前，该引用变量指向的对象的 final 成员变量已经在构造函数内被初始化完成了。在构造函数内部，不能让这个被构造对象的引用为其他线程可见，也就是对象的引用不能在构造函数中逃逸出。示例代码如下：

package com.yj.final_;
/**
 * @description: final 逃逸
 * @author: erlang
 * @since: 2021-01-19 21:58
 */
public class FinalEscapeExample {
    final int value;
    static FinalEscapeExample obj;
    public FinalEscapeExample() {
        this.value = 1; // 1 写 final 变量
        obj = this; // 2 this 引用在此逃逸出
    }
    public static void writer() {
        new FinalEscapeExample();
    }
    public static void reader() {
        if (obj != null) { // 3
            int value = obj.value; // 4
        }
    }
}

假设线程 A 执行 writer 方法，另一个线程 B 执行 reader 方法。这里的操作 2 使得对象还未完成构造前就对线程 B 可见。即使这里的操作 2 是构造函数的最后一步，且在程序中操作 2 排在操作 1 后面，执行 reader 方法的线程仍然可能无法看到 final 变量被初始化后的值，因为这里的操作 1 和操作 2 之间可能被重排序。实际执行的时序如图所示：

从上图可以看出，在构造函数返回之前，被构造对象的引用不能对其他线程所见，因为此时的 final 变量可能还未被初始化。在构造函数返回后，任意线程都将保证能看到 final 变量初始化之后的值。

3.6、final 语义在处理器中的实现

这里以 X86 处理器为例，说明 final 语义在处理器中的具体实现。前面有说，写 final 变量的重排序规则会要求编译器在 final 变量的写之后，构造函数 return 之前插入一个 StoreStore 屏障。读 final 变量的重排序规则要求编译器在读 final 变量的操作前面插入一个 LoadLoad 屏障。

由于 X86 处理器不会对写-写操作做重排序，所以在 X86 处理器中，写 final 变量需要的 StoreStore 也会被省略掉。同样，由于 X86 处理器不会对间接依赖关系的操作做重排序，所以在 X86 处理器中，读 final 变量需要的 LoadLoad 屏障也会被省略掉。也就是说处理器中，final 变量的读/写不会插入任何内存屏障。

3.7、JSR-133 为什么要增强 final 的语义

在旧的 Java 内存模型中，一个最严重的缺陷就是线程可能看到 final 变量的值会改变。比如，一个线程当前看到一个整型 final 变量的值为 0（还未初始化之前的默认值），过一段时间之后这个线程在去读这个 final 变量的值时，却发现变为 1（被某个线程初始化之后的值）。常见的例子就是旧的 Java 内存模型中，String 的值可能会改变。

为了修补这个漏洞，JSR-133 增强了 final 的语义。通过为 final 变量增加写和读重排序规则，可以为 Java 程序员提供初始化安全保证，只要对象是正确构建的（被构造对象的引用在构造函数中没有逃逸出去），那么不需要使用同步（指 lock 和 volatile 的使用）就可以保证任意线程都能看到这个 final 变量在构造函数中被初始化后的值。