Java Memory Model

当一个变量定义为 volatile 之后，某个线程修改了这个变量的值，其它线程可立即得知，这就是“可见性”。 普通变量（没有用 volatile 修饰）不能做到这一点，普通变量的值在线程间传递均需要通过主内存来完成，例如，线程 A 修改一个普通变量的值，然后向主内存进行回写，另外一条线程 B 在线程 A 回写完成了之后再从主内存进行读取操作，新变量值才会对线程 B 可见。

但是，volatile 变量的运算在并发下不一定是安全的。我们通过一个简单的例子来说明原因。

// 这个例子中，volatile变量在并发下是不安全的！
public class VolatileTest {

    public static volatile int race = 0;

    public static void increase() {
        race++;
    }

    private static final int THREAD_COUNT = 20;

    public static void main(String[] args) {
        Thread[] threads = new Thread[THREAD_COUNT];
        for (int i = 0; i < THREAD_COUNT; i++) {
            threads[i] = new Thread(new Runnable() {

                @Override
                public void run() {
                    for (int i = 0; i < 10000; i++) {
                        increase();
                    }
                }
            });
            threads[i].start();
        }

        // 等待所有累加线程都结束
        while (Thread.activeCount() > 1) {
            Thread.yield();
        }

        System.out.println(race);
    }
}

上面这段代码发起了 20 个线程，每个线程对 race 变量进行 10000 次自增操作，如果这段代码能够正确并发的话，最后输出的结果应该是 200000。但是，运行这段代码并不会获得期望的结果，每次运行的输出结果都不一样，都是一个小于 200000 的数字，这是为什么呢？

问题出在方法 increase 中自增运算“race++”，用 javap 反编译后得到的代码如下所示：

$ javap -c VolatileTest
Compiled from "VolatileTest.java"
public class VolatileTest {
  public static volatile int race;

  public VolatileTest();
    Code:
       0: aload_0
       1: invokespecial #1                  // Method java/lang/Object."<init>":()V
       4: return

  public static void increase();
    Code:
       0: getstatic     #2                  // Field race:I
       3: iconst_1
       4: iadd
       5: putstatic     #2                  // Field race:I
       8: return

......
}

从上面代码中可以发现，increase()方法在 Class 文件中由 4 条字节码指令构成（return 指令不是由 race++产生的，这条指令可以不计算），从字节码层面上很容易就分析出并发失败的原因了：当 getstatic 指令把 race 的值取到操作栈顶时，volatile 关键字保证了 race 的值在此时是正确的，但是在执行 iconst_1、iadd 这些指令的时候，线程可能已经把 race 的值加大了，而在操作栈顶的值就变成了过期的数据，所以 putstatic 指令执行后就可能把较小的 race 值同步回主内存之中。
需要注意的是，使用字节码来分析并发问题是不严谨的，因为即使编译出来只有一条字节码指令，也并不意味执行这条指令就是一个原子操作。一条字节码指令在解释执行时，解释器将运行许多行代码才能实现它的语义；如果是编译执行，一条字节码指令可能转化为多条本地机器码指令。不过，在上面这个例子中，使用字节码已经能说明问题了，所以在此处使用字节码来分析。

那么，如何修改前面的程序，使得在并发情况下得到期待的结果呢（即输出 200000）呢？
第一个修正方法是：用 synchronized 修饰方法 increase（这时，race 不需要用 volatile 修饰了），如：

......
    public static int race = 0;  // 方法increase加上synchronized后，race不需要用volatile修饰了

    public static synchronized void increase() {
        race++;
    }
......

第二个修正方法是：把 race 改为原子类 AtomicInteger，如：

......
    public static AtomicInteger race = new AtomicInteger(0);

    public static void increase() {
        race.incrementAndGet();
    }
......

volatile boolean shutdownRequested;

public void shutdown() {
   shutdownRequested = true;       // 满足上面提到的两条规则（不依赖于变量的当前值，也不需要与其他状态变量共同参与不变约束）
}

public void doWork() {
    while (!shutdownRequested) {
        // do stuff
    }
}

volatile 变量的第二个特性是：禁止指令重排序优化。

先介绍一下什么是“指令重排序”。现代处理器采用指令级并行技术(Instruction-level parallelism)允许将多条指令不按程序规定的顺序分开发送给各个相应电路单元处理，这样指令被“重排序”了，但并不是说指令任意地重排，CPU 需要能正确处理指令依赖情况以保障程序能得出正确的执行结果。譬如指令 1 把地址 A 中的值加 10，指令 2 把地址 A 中的值乘以 2，指令 3 把地址 B 中值减去 3，这时指令 1 和指令 2 是有依赖的，它们之间的顺序不能重排——因为(A+10)*2 与 A*2+10 显然是不相等的，但是指令 3 可以重排到指令 1、2 之前或者中间，只要保证 CPU 执行后面依赖的 A、B 值的操作时能获得正确的 A 和 B 值即可。

既然 CPU 需要能正确处理指令依赖情况，为什么还要禁止指令重排序呢？ 因为程序中可能有一些“人为的依赖关系”，这是 CPU 无法得知的。

下面是“指令重排序”可能干扰程序并发执行的演示程序。

Map configOptions;
char[] configText;
volatile boolean initialized = false; // initialized 在此必须定义为volatile


// 假设以下代码在线程 A 中执行
// 模拟读取配置信息，当读取完成后将 initialized 设置为 true 以通知其他线程配置可用
configOptions = new HashMap();
configText = readConfigFile(fileName);
processConfigOptions(configText, configOptions);
initialized = true;


// 假设以下代码在线程 B 中执行
// 等待 initialized 为 true，代表线程 A 已经把配置信息初始化完成
while (!initialized) {
    sleep();
}
// 使用线程 A 中初始化好的配置信息
doSomethingWithConfig();

上面是一段伪代码，其中描述的场景十分常见，只是我们在处理配置文件时一般不会出现并发而已。

如果定义 initialized 变量时没有使用 volatile 修饰，就可能由于指令重排序的优化，导致位于线程 A 中最后一句的代码 initialized=true 被提前执行（这里虽然使用 Java 作为伪代码，但所指的重排序优化是机器级的优化操作，提前执行是指这句话对应的汇编代码被提前执行），这样在线程 B 中使用配置信息的代码就可能出现错误，而 volatile 关键字则可以避免此类情况的发生。

说明： Java 5 以前的 Java 内存模型是存在缺陷的，即时将变量声明成 volatile 也不能完全避免重排序，这个问题已经在 Java 5 及更高版本中修正。

Java 中要实现多线程安全的单例模式，可以用下面的代码：

// 懒汉式单例模式（多线程安全）
public class Singleton {
    private static Singleton instance;
    private Singleton () {}

    public static synchronized Singleton getInstance() {
        if (instance == null) {
            instance = new Singleton();
        }
        return instance;
    }
}

//// 仅为方便对比，下面给出饿汉式单例模式（多线程安全）
//public class Singleton {
//    private static final Singleton instance = new Singleton();
//    private Singleton () {}
//
//    public static Singleton getInstance() {
//        return instance;
//    }
//}

在上面懒汉式单例模式的实现中，synchronized 修饰了整个 getInstance()方法，故同时只有一个线程可以调用 getInstance()方法，不是很高效。其实，同步操作只需要在第一次创建单例实例对象时才需要，从而引出了 Double-checked locking(DCL)。下面是 Java 中 DCL 的实现：

// 懒汉式单例模式（多线程安全），性能更好
// 说明：这种实现在Java 1.5及更高版本才正确工作
public class Singleton {
    private volatile static Singleton instance; // instance必须声明为volatile，后文将说明原因。
    private Singleton () {}

    public static Singleton getSingleton() {
        if (instance == null) {                 // 第一次非空检测。
            synchronized (Singleton.class) {
                if (instance == null) {         // 第二次非空检测。需要它的原因是可能有多个线程一起进入同步块外的if（通过第一次非空检测），如果不进行第二次检测，则会生成多个实例。
                    instance = new Singleton();
                }
            }
        }
        return instance;
    }
}

在 Java 的 DCL 实现中，为什么需要把 instance 声明为 volatile 呢？这是因为这行代码 instance = new Singleton(); 不是原子操作，可以分解为下面三行伪代码：

mem = allocate();      // 1. 给 instance 分配内存
createInstance(mem);   // 2. 调用 Singleton 的构造函数来初始化对象
instance = mem;        // 3. 将 instance 对象指向分配的内存空间，这时instance为非null

如果 instance 是未用 volatile 修饰的普通变量，上面三行伪代码中的 2 和 3 之间，可能会被重排序，因为重排序 2 和 3 并不会破坏线程内语义(intra-thread semantics)。2和 3 之间重排序之后的执行时序如下：

mem = allocate();      // 1. 给 instance 分配内存
instance = mem;        // 3. 将 instance 对象指向分配的内存空间，这时instance为非null
createInstance(mem);   // 2. 调用 Singleton 的构造函数来初始化对象

如果按 1-3-2 的执行顺序，当 3 执行完毕，2还未执行之前，被另外一个线程（记为线程 B）抢占了，那么 instance 已经是非 null 了（但却没有初始化），所以线程 B 直接返回 instance，然后使用，从而会报错（由于 instance 未初始化）。

我们将 instance 变量声明成 volatile 后，就可以禁止指令重排序优化，这样上面伪代码的执行顺序一定是 1-2-3，不会有问题了。

参考：http://www.infoq.com/cn/articles/double-checked-locking-with-delay-initialization

假设有下面代码：

private int value=0;

pubilc void setValue(int value) {
    this.value=value;
}

public int getValue() {
    return value;
}

上面是一组再普通不过的 getter/setter 方法，假设存在线程 A 和 B，线程 A 先（时间上的先后）调用了“setValue(1)”，然后线程 B 调用了同一个对象的“getValue()”，那么线程 B 收到的返回值是什么？

我们依次分析一下“先行发生”原则中的 8 条规则，由于两个方法分别由线程 A 和线程 B 调用，不在一个线程中，所以程序次序规则在这里不适用；由于没有同步块，自然就不会发生 lock 和 unlock 操作，所以管程锁定规则不适用；由于 value 变量没有被 volatile 关键字修饰，所以 volatile 变量规则不适用；后面的线程启动、终止、中断规则和对象终结规则也和这里完全没有关系。因为没有一个适用的先行发生规则，所以最后一条传递性也无从谈起，因此我们可以判定尽管线程 A 在操作时间上先于线程 B，但是无法确定线程 B 中“getValue()”方法的返回结果，换句话说，这里的操作不是线程安全的。

那怎么修复这个问题呢？我们至少有两种比较简单的方案可以选择：要么把 getter/setter 方法都定义为 synchronized 方法，这样就可以套用管程锁定规则；要么把 value 定义为 volatile 变量，由于 setter 方法对 value 的修改不依赖 value 的原值，满足 volatile 关键字使用场景，这样就可以套用 volatile 变量规则来实现先行发生关系。

通过上面的例子，我们可以得出结论：一个操作“时间上的先发生”不代表这个操作会是“先行发生”。

假设有下面代码：

// 以下操作在同一个线程中执行
int i = 1;
int j = 2;

设上面两条赋值语句在同一个线程中执行，根据程序次序规则，“int i=1”的操作先行发生于“int j=2”。但“int j=2”的代码完全可能先被处理器执行，这并不影响先行发生原则的正确性。

操作A先行发生于操作B，是指在发生操作B之前，操作A产生的影响能被操作B观察到。在这个例子中，“int i=1”和“int j=2”没有什么依赖关系，处理器可以随便对它们进行“重排序”。

这个例子中，如果把“int j=2;”改为“int j=i;”，则“int i=1”一定会被处理器先执行。