78. 同步访问共享的可变数据

　　这种观点是正确的，但是它并没有说明同步的全部意义。如果没有同步，一个线程的变化就不能被其他线程看到。同步不仅可以阻止一个线程看到对象处于不一致的状态之中，它还可以保证进入同步方法或者同步代码块的每个线程，都能看到由同一个锁保护的之前所有的修改效果。

　　Java 语言规范保证读或者写一个变量是原子的（ atomic ），除非这个变量的类型为 long 或者 double [JLS , 17.4, 17.7］。换句话说，读取一个非 long 或 double 类型的变量，可以保证返回值是某个线程保存在该变量中的，即使多个线程在没有同步的情况下并发地修改这个变量也是如此。

　　你可能昕说过，为了提高性能，在读或写原子数据的时候，应该避免使用同步。这个建议是非常危险而错误的。虽然语言规范保证了线程在读取原子数据的时候，不会看到任意的数值，但是它并不保证一个线程写入的值对于另一个线程将是可见的。 为了在线程之间进行可靠的通信，也为了互斥访问，同步是必要的。 这归因于 Java 语言规范中的内存模型（memory model），它规定了一个线程所做的变化何时以及如何变成对其他线程可见[JLS ,17.4; Goetz06, 16]。

　　如果对共享的可变数据的访问不能同步，其后果将非常可怕，即使这个变量是原子可读写的。以下面这个阻止一个线程妨碍，另一个线程的任务为例。Java 的类库中提供了 Thread.stop 方法，但是在很久以前就不提倡使用该方法了，因为它本质上是不安全的一一使用它会导致数据遭到破坏。 千万不要使用 Thread.stop 方法。 要阻止一个线程妨碍另一个线程，建议的做法是让第一个线程轮询（ poll ）一个 boolean 字段，这个字段一开始为 false ，但是可以通过第二个线程设置为 true ，以表示第一个线程将终止自己。由于 boolean 字段的读和写操作都是原子的，程序员在访问这个字段的时候不再需要使用同步：

　　你可能期待这个程序运行大约一秒钟左右，之后主线程将 stopRequested 设置为 true ，致使后台线程的循环终止。但是在我的机器上，这个程序永远不会终止：因为后台线程永远在循环！

while (!stopRequested)
    i++;

　　转变成这样：

　　这种优化称作提升（ hoisting ），正是 OpenJDK Server VM 的工作。结果是一个活性失败（liveness failure）：这个程序并没有得到提升。修正这个问题的一种方式是同步访问 stopRequested字段。这个程序会如预期般在大约一秒之内终止：

// Properly synchronized cooperative thread termination
public class StopThread {
    private static Boolean stopRequested;
    private static synchronized void requestStop() {
        stopRequested = true;
    }
    private static synchronized Boolean stopRequested() {
    }
    public static void main(String[] args)
            throws InterruptedException {
        Thread backgroundThread = new Thread(() -> {
            int i = 0;
            while (!stopRequested())
                i++;
        });
        backgroundThread.start();
        requestStop();
}

　　注意写方法（ requestStop ）和读方法（ stopRequested ）都被同步了。只同步写方法还不够！ 除非读和写操作都被同步，否则无法保证同步能起作用。 有时候，会在某些机器上看到只同步了写（或读）操作的程序看起来也能正常工作，但是在这种情况下，表象具有很大的欺骗性。

　　StopThread 中被同步方法的动作即使没有同步也是原子的。换句话说，这些方法的同步只是为了它的通信效果，而不是为了互斥访问。虽然循环的每个迭代中的同步开销很小，还是有其他更正确的替代方法，它更加简洁，性能也可能更好。如果 stopRequested 被声明为 volatile ，第二种版本的 StopThread 中的锁就可以省略。虽然 volatile 修饰符不执行互斥访问，但它可以保证任何一个线程在读取该字段的时候都将看到最近刚刚被写入的值：

　　在使用 volatile 的时候务必要小心。以下面的方法为例，假设它要产生序列号：

// Broken - requires synchronization!
private static volatile int nextSerialNumber = 0;
public static int generateSerialNumber() {
    return nextSerialNumber++;
}

　　问题在于，增量操作符（++）不是原子的。它在 nextSerialNumber 字段中执行两项操作：首先它读取值，然后写回一个新值，相当于原来的值再加上 1。如果第二个线程在第一个线程读取旧值和写回新值期间读取这个字段第二个线程就会与第一个线程一起看到同一个值，并返回相同的序列号。这就是安全性失败（ safety failure ）：这个程序会计算出错误的结果。

　　修正 generateSerialNumber 方法的一种方法是在它的声明中增加 synchronized 修饰符。这样可以确保多个调用不会交叉存取，确保每个调用都会看到之前所有调用的效果。一旦这么做，就可以且应该从 nextSerialNumber 中删除 volatile 修饰符。为了保护这个方法，要用 long 代替 int ，或者在 nextSerialNumber 要进行包装时抛出异常。

　　最好还是遵循第 59 条中的建议，使用类，它是 java.util.concurrent.atomic 的组成部分。这个包为在单个变量上进行免锁定、线程安全的编程提供了基本类型。虽然 volatile 只提供了同步的通信效果，但这个包还提供了原子性。这正是你想让 generateSerialNumber 完成的工作，并且它可能比同步版本完成得更好：

　　避免本条目中所讨论到的问题的最佳办法是不共享可变的数据。要么共享不可变的数据（详见第 17 条），要么压根不共享。换句话说， 将可变数据限制在单个线程中。 如果采用这一策略，对它建立文档就很重要，以便它可以随着程序的发展而得到维护。深刻地理解正在使用的框架和类库也很重要，因为它们引入了你不知道的线程。

　　让一个线程在短时间内修改一个数据对象，然后与其他线程共享，这是可以接受的，它只同步共享对象引用的动作。然后其他线程没有进一步的同步也可以读取对象，只要它没有再被修改。这种对象被称作高效不可变（ effectively immutable ) [Goetz06, 3.5.4] 。将这种对象引用从一个线程传递到其他的线程被称作安全发布（ safe publication) [Goetz06, 3.5.3] 。安全发布对象引用有许多种方法：可以将它保存在静态字段巾，作为类初始化的一部分；可以将它保存在 volatile 字段、final 字段或者通过正常锁定访问的字段中；或者可以将它放到并发的集合中（详见第 81 条）。