16.1 什么是内存模型，为什么需要它

假设一个线程为变量 aVariable 赋值：

aVariable = 3;

内存模型需要解决这个问题：“在什么条件下，读取 aVariable 的线程将看到这个值为 3？”这听起来似乎是一个愚蠢的问题，但如果缺少同步，那么将会有许多因素使得线程无法立即甚至永远，看到另一个线程的操作结果。在编译器中生成的指令顺序，可以与源代码中的顺序不同，此外编译器还会把变量保存在寄存器而不是内存中；处理器可以采用乱序或并行等方式来执行指令；缓存可能会改变将写入变量提交到主内存的次序；而且，保存在处理器本地缓存中的值，对于其他处理器是不可见的。这些因素都会使得一个线程无法看到变量的最新值，并且会导致其他线程中的内存操作似乎在乱序执行——如果没有使用正确的同步。

16.1.2 重排序

程序清单 16-1 说明了重排序可能造成的后果：

// 程序清单 16-1
public class PossibleReordering {
    static int x = 0, y = 0;
    static int a = 0, b = 0;
    
    public static void main(String[] args) throws InterruptedException {
        Thread one = new Thread(() -> {
            a = 1;
            x = b;
        });
        Thread other = new Thread(() -> {
            b = 1;
            y = a;
        });
        one.start(); other.start();
        one.join(); other.join();
        System.out.println("( " + x + ", " + y + ")");
    }
}

很容易想象 PossibleReordering 是如何输出 （1, 0）或（0, 1）或（1, 1）的：线程 A 可以在线程 B 开始之前就执行完成，线程 B 也可以在线程 A 开始之前执行完成，或者二者的操作交替执行。但奇怪的是，PossibleReordering 还可以输出（0, 0）。这正是由于指令的重排序导致的。

如果没有同步，那么推断出执行顺序时非常困难的，而要确保在程序中正确地使用同步却是非常容易的。同步将限制编译器、运行时和硬件对内存操作重排序的方式，从而在实施重排序时不会破坏 JMM 提供的可见性保证。

16.1.3 Java 内存模型简介

Java 内存模型是通过各种操作来定义的，包括对变量的读/写操作，监视器的加锁和释放操作，以及线程的启动和合并操作。要想保证执行操作 B 的线程看到操作 A 的结果（无论 A 和 B 是否在同一个线程中执行），那么在 A 和 B 之间必须满足 Happens-Before 关系。如果两个操作之间缺乏 Happens-Before 关系，那么 JVM 可以对它们任意地重排序。

Hanppens-Before 的规则包括：
程序顺序规则。如果程序中操作 A 在操作 B 之前，那么在线程中 A 操作将在 B 操作之前执行。
监视器锁规则。在监视器锁上的解锁操作必须在同一个监视器锁上的加锁操作之前执行。
volatile 变量规则。对 volatile 变量的写入操作必须在对该变量的读操作之前执行。
线程启动规则。在线程上对 Thread.start 的调用必须在该线程中执行任何操作之前执行。
线程结束规则。线程中的任何操作都必须在其他线程检测到该线程已经结束之前执行，或者从 Thread.join 中成功返回，或者在调用 Thread.isAlive 时返回 false。
中断规则。当一个线程在另一个线程上调用 interrupt 时，必须在被中断线程检测到 interrupt 调用之前执行（通过抛出 InterruptedException，或者调用 isInterrupted 和 interrupted）
终结器规则。对象的构造函数必须在启动该对象的终结器之前执行完成。
传递性。如果操作 A 在操作 B 之前执行，并且操作 B 在操作 C 之前执行，那么操作 A 必须在操作 C 之前执行。

16.1.4 借助同步

由于 Happens-Before 的排序功能很强大，因此有时候可以 “借助（Piggyback）”现有同步机制的可见性属性。这需要将 Happens-Before 的程序顺序与其他某个顺序规则（通常是监视器锁规则或者 volatile 变量规则）结合起来，从而对某个未被锁保护的变量的访问操作进行排序。它是一项高级技术，并且只有当需要最大限度地提升某些类（例如 ReentrantLock）的性能时，才应该使用这项技术。

之所以将这项技术称为“借助”，是因为它使用了一种现有的 Happens-Before 顺序来确保对象 X 的可见性，而不是专门为了发布 X 而创建一种 Happens-Before 顺序。

在类库中提供的其他 Happens-Before 排序包括：

• 将一个元素放入一个线程安全容器的操作将在另一个线程从该容器中获得这个元素的操作之前执行。
• 在 CountDownLatch 上的倒数操作将在线程从闭锁上的 await 方法中返回之前执行。
• 释放 Semaphore 许可的操作将在从该 Semaphore 上获得一个许可之前执行。
• Future 表示的任务的所有操作将在从 Future.get 中返回之前执行。
• 向 Executor 提交一个 Runnable 或 Callable 的操作将在任务开始执行之前执行。

16.2 发布

16.2.1 不安全的发布

造成不正确发布的真正原因，就是在 “发布一个共享对象” 与 “另一个线程访问该对象” 之间缺少一种 Happens-Before 排序。

当缺少 Happens-Before 关系时，就可能出现重排序问题，这就解释了为什么在没有充分同步的情况下发布一个对象会导致另一个线程看到一个只被部分构造的对象。

错误的延迟初始化将导致不正确的发布，如下面的 程序清单 16-3 所示。

// 程序清单 16-3
public class UnsafeLazyInitialization {
    private static Resource resource;
    
    public static Resource getInstance() {
        if (resource == null) {
            resource = new Resource();  // 不安全的发布
        }
        return resource;
    }
}

除了不可变对象以外，使用被另一个线程初始化的对象通常都是不安全的，除非对象的发布操作是在使用该对象的线程开始使用之前执行。

16.2.3 安全初始化模式

有时候，我们需要推迟一些高开销的对象初始化操作，并且只有当使用这些对象时才进行初始化，但我们也看到了在误用延迟初始化时导致的问题。在 程序清单 16-4 中，通过将 getResource 方法声明为 synchronized，可以修复 UnsafeLazyInitialization 中的问题。

// 程序清单 16-4 线程安全的延迟初始化
public class SafeLazyInitialization {
    private static Resource resource;
    
    public synchronized static Resource getInstance() {
        if (resource == null) {
            resource = new Resource();
        }
        return resource;
    }
}

由于 getInstance 的代码路径很短（只包含一个判断预见和一个预测分支），因此如果 getInstance 没有被很多个线程频繁调用，那么在 SafeLazyInitialization 上不会存在激烈的竞争，从而能提供令人满意的性能。

在初始化器中采用了特殊的方式来处理静态域（或者在静态初始化代码块中初始化的值），并提供了额外的线程安全性保证。静态初始化器是由 JVM 在类的初始化阶段执行，即在类被加载后并且在被线程使用之前。由于 JVM 将在初始化期间获得一个锁，并且每个线程都至少获取一次这个锁以确保这个类已经被加载（Happens-Before），因此在静态初始化期间，内存写入操作将自动对所有线程可见。因此无论是在被构造期间还是被引用时，静态初始化的对象都不需要显式的同步。然而，这个规则仅适用于在构造时的状态，如果对象是可变的，那么在读取线程和写线程之间仍然需要通过同步来确保随后的修改操作是可见的，以避免数据被破坏。

通过使用提前初始化（Eager Initialization），避免了在每次调用 SafeLazyInitialization 中的 getInstance 时所产生的的同步开销：

// 程序清单 16-5 提前初始化
public class EagerInitialization {
    private static Resource resource = new Resource();  // 利用静态初始化器保证可见性

    public static Resource getResouce() {
        return resouce;
    }
}

通过将上面的静态初始化器的技术和延迟初始化的需求结合起来，我们可以形成一种延迟初始化技术，从而在常见的代码路径中不需要同步。在 程序清单 16-6 的 “延迟初始化占位（Holder） 类模式” 中使用了一个专门的类来初始化 Resource。JVM 将推迟 ResourceHolder 的初始化操作，直到开始使用这个类时才初始化，并且由于通过一个静态初始化来初始化 Resource，因此不需要额外的同步。当任何一个线程第一次调用 getResouce 时，都会使 ResourceHolder 被加载和被初始化，此时静态初始化器将执行 Resouce 的初始化操作。

// 程序清单 16-6 延长初始化占位类模式
public class ResourceFactory {
    private static class ResourceHolder {
        public static Resource resouce = new Resource();  // 利用静态初始化器保证同步
    }
    
    public static Resource getResource() {
        return ResourceHolder.resouce;
    }
}

16.2.4 双重检查加锁

我们再来看看声名狼藉的双重检查加锁（DCL），如 程序清单 16-7 所示。在早期的 JVM 中，同步（甚至是无竞争的同步）都存在着巨大的性能开销。因此，人们想出了许多“聪明的（或者至少看上去聪明）”技巧来降低同步的影响，有些技巧很好，但也有些技巧是不好的，甚至是糟糕的，DCL 就属于“糟糕”的一类。

// 程序清单 16-7 双重检查加锁（不要这么做）
public class DoubleCheckedLocking {
    private static Resource resource;  // 注意这里没有使用 volatile
    
    public static Resource getInstance() {
        if (resource == null) {
            synchronized (DoubleCheckedLocking.class) {
                if (resource == null) {
                    resource = new Resource();
                }
            }
        }
        return resource;
    }
}

上面的代码看似在获取 Resource 过程中都是用了同步，从而不是两个线程都分别构造一个 Resource 实例，但是在获取一个已构造好的 Resource 引用，并没有使用同步。这就是问题所在：线程可能看到一个仅被部分构造的 Resource。在 JMM 的后续版本中，如果把 resource 声明为 volatile 类型，那么就能启用 DCL，并且这种方式对性能的影响很小，因为 volatile 变量读取操作的性能通常只是略高于非 volatile 变量读取操作的性能。然而，DCL 的这种使用方法已被广泛地废弃了——延迟初始化占位类模式能带来同样的优势，并且更容易理解。

16.3 初始化过程中的安全性

如果能确保初始化过程的安全性，那么就可以使得被正确构造的不可变对象在没有同步的情况下也能安全地在多个线程之间共享，而不管它们是如何发布的，甚至通过某种数据竞争来发布。

初始化安全性将确保，对于被正确构造的对象，所有线程都能看到由构造函数为对象给各个 final 域设置的正确值，而不管采用何种方式来发布对象。而且，对于可以通过被正确构造对象中某个 final 域到达的任意变量（例如某个 final 数组中的元素，或者由一个 final 域引用的 HashMap 的内容）将同样对于其他线程是可见的。

初始化安全性意味着，程序清单 16-8 的 SafeStates 可以安全地发布。

// 程序清单 16-8 不可变对象的初始化安全性
public class SafeStates {
    private final Map<String, String> states;  // final 保证了 states 的初始化一定在对象构造完成之前
    
    public SafeStates() {
        states = new HashMap<>();
        states.put("alaska", "AK");
        states.put("alabama", "AL");
        states.put("wyoming", "WY");
    }
    
    public String getAbbreviation(String s) {
        return states.get(s);
    }
}