关键字synchronized可以保证在同一时刻，只有一个线程可以执行某一个方法，或者某一个代码块。许多程序猿把同步的概念仅仅理解为一种互斥的方式（mutual exclusion），即，当一个对象被一个线程修改的时候，可以阻止另一个线程观察到对象内部不一致的状态。按照这种观点，对象被创建的时候处于一致的状态（第17项），当有方法访问它的时候，它就被锁定了。这些方法观察到对象的状态，并且可能会引起状态转变（state transition），即把对象从一种一致的状态转换到另一种一致的状态。正确地使用同步可以保证没有任何方法会看到对象处于不一致的状态中。
这种观点是正确的，但它只说出了同步的一半意义。如果没有同步，一个线程的变化就不能被其他线程看到。同步不仅可以阻止一个线程看到对象处于不一致的状态之中，它还可以保证进入同步方法或者同步代码块的每个线程，都看到由同一个锁保护的之前所有的修改效果。
Java语言规范保证读或者写一个变量是原子的（atomic），除非这个变量的类型为long或者double[JLS, 17.4, 17.7]。换句话说，读取一个非long或double类型的变量，可以保证返回的值是某个线程保存在该变量中的，即使多个线程在没有同步的情况下并发地修改这个变量也是如此。
你可能听说过，为了提高性能，在读写原子数据的时候，应该避免使用同步。这个建议是非常危险而错误的。虽然语言规范保证了线程在读取原子数据的时候，不会看到任意的数值，但是它并不保证一个线程写入的值对另一个线程将是可见的。为了在线程之间进行可靠的通信，也为了互斥访问，同步是必要的 。这主要是因为Java语言规范中的内存模型（memory model），它规定了一个线程所做的变化何时以及如何变成对其他线程可见[JLS, 17.4; Goetz06, 16]。
如果对共享的可变数据的访问不能同步，其后果将非常可怕，即使这个变量是原子可读写的。考虑下面这个在一个线程中将另一个线程终止（stop）的任务。Java类库中提供了Thread.stop方法，但是这个方法在很久以前就不提倡使用了，因为它本质上是不安全的——使用它会导致数据遭到破坏。不要使用Thread.stop 。要在一个线程终止另一个线程，建议的做法是让第一个线程轮询（poll）一个boolean域，这个域一开始为false，但是可以通过第二个线程设置为true，这样来表示第一个线程要终止自己。由于boolean域的读和写操作都是原子的，程序猿在访问这个域的时候不再使用同步。
// Broken! - How long would you expect this program to run?
public class StopThread {
private static boolean stopRequested;
public static void main(String[] args) throws InterruptedException {
Thread backgroundThread = new Thread(() -> {
int i = 0;
while (!stopRequested)
i++;
});
backgroundThread.start();
TimeUnit.SECONDS.sleep(1);
stopRequested = true;
}
}
你可能期待这个程序运行大约一秒钟左右，之后主线程将stopRequested设置为true，致使后台线程的循环终止。但是在我的机器上，这个程序*永远（never）*不会终止：因为后台线程永远在循环！
这个问题在于，由于没有同步，就不能保证后台线程何时“看到”主线程对stopRequested的值所做的改变。没有同步，虚拟机将代码：
while(!stopRequested)
i++;
转变成这样：
while(!stopRequested)
while(true)
i++;
这种优化称为提升(hoisting)，它正是OpenJDK Server VM所做的。结果是一个活性失败（liveness failure）：这个程序无法前进（the program fails to make progress）【无法继续往下执行的意思吗…】。修正这个问题的一种方式是同步访问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() {
return stopRequested;
}
public static void main(String[] args) throws InterruptedException {
Thread backgroundThread = new Thread(() -> {
int i = 0;
while (!stopRequested())
i++;
});
backgroundThread.start();
TimeUnit.SECONDS.sleep(1);
requestStop();
}
}
注意写方法（requestStop）和读方法（stopRequest）都被同步了。只同步写方法还不够！除非读和写操作都被同步，否则就无法保证同步就会起作用 。偶尔只能同步写入（或读取）的程序似乎可以在某些机器上运行，但在这种情况下，它表现出来的现象是具有欺骗性的。
StopThread【线程】里在同步方法中的动作即使没有同步也是原子的。换句话说，这些方法的同步只是为了它的通信效果，而不是为了互斥访问。虽然循环的每个迭代中的同步开销很小，还是有其他正确的替代方法，它更加简洁，性能也可能更好。如果stopRequested被声明为volatile，第二种版本的StopThread中的锁就可以省略。虽然volatile修饰符不执行互斥访问，但它可以保证任何一个线程在读取该域的时候都将看到最近刚刚被写入的值：
// Cooperative thread termination with a volatile field
public class StopThread {
private static volatile boolean stopRequested;
public static void main(String[] args) throws InterruptedException {
Thread backgroundThread = new Thread(() -> {
int i = 0;
while (!stopRequested)
i++;
});
backgroundThread.start();
TimeUnit.SECONDS.sleep(1);
stopRequested = true;
}
}
在使用volatile的时候务必要小心。考虑下面的方法，假设它要产生序列号：
// Broken - requires synchronization!
private static volatile int nextSerialNumber = 0;
public static int generateSerialNumber() {
return nextSerialNumber++;
}
这个方法的目的是要确保每个调用都返回不同的值（只要不超过2^32次调用）。这个方法的状态只包含一个可原子访问的域：nextSerialNumber，这个域的所有可能的值都是合法的。因此，不需要任何同步来保护它的约束条件。然而，如果没有同步，这个方法仍然无法正常工作。
问题在于，自增操作符（++）不是原子的。它的nextSerialNumber域中执行两项操作：首先它读取值，然后写回一个新值，相当于原来的值再加1。如果第二个线程在线程读取旧值并写回新值之间读取域，则第二个线程将看到与第一个线程相同的值并返回相同的序列号。这是*安全性失败（safety failure）：程序会计算出错误的结果。
修复generateSerialNumber的一种方法是将synchronized修饰符添加到其声明中。这确保了多个调用之间不会【出现】交叉，并且每次调用该方法都会看到先前【执行的】所有调用【方法执行之后】的效果。一旦你这么做了，就可以并且应该从nextSerialNumber中删除volatile修饰符。为了让这个方法更可靠，要用long代替int，或者在nextSerialNumber快要重叠时抛出异常。
最好还是遵循第59项中的建议，使用类AtomicLong，它是java.util.concurrent.atomic的一部分。该软件包为基本类型的单个变量提供了无锁，线程安全的编程【方式】（This package provides primitives for lock-free, thread-safe programming on single variables）。虽然volatile只提供同步的通信效果，但这个包也提供了原子性。这正是我们想要的generateSerialNumber，它可能比使用同步的版本更好：
// Lock-free synchronization with java.util.concurrent.atomic
private static final AtomicLong nextSerialNum = new AtomicLong();
public static long generateSerialNumber() {
return nextSerialNum.getAndIncrement();
}
避免本项中所讨论到地问题的最佳办法是不共享可变的数据。要么共享不可变的数据（第17项），要么压根不共享。换句话说，将可变数据限制在单个线程中 。如果采用这一策略，为它建立文档就很重要，以便该策略可以随着程序的发展而得到维护。深刻地理解正在使用的框架和类库也很重要，因为它们引入了你所不知道的线程。
让一个线程在短时间内修改一个数据对象，然后与其他线程共享，这是可以接受的，【因为】这个动作只是同步共享对象引用。其他线程只要不对该对象再次进行修改，那么其他线程不需要使用同步就能读取该对象（Other threads can then read the object without further synchronization, so long as it isn’t modified again）。这种对象被称作事实上不可变的（effectively immutable）[Goetz06, 3.5.4]。将这种对象的引用从一个线程传递到其他线程【的操作】称作安全发布（safe publication）[Goetz06, 3.5.3]。安全发布对象引用有许多种方法：你可以将它存储在volatile修饰的字段、final字段、或者通过正常锁定访问的字段（a field that is accessed with normal locking）；或者你可以将它放到并发的集合中（第81项）。
简而言之，当多个线程共享可变数据的时候，每个读或者写数据的线程都必须执行同步 。如果没有同步，就无法保证一个线程所做的修改对另一个线程是可见的。未能同步共享可变数据会造成程序的活性和安全性失败（liveness and safety failures）。这样的失败是最难以调试的。它们可能是间歇性的，且与时间相关，程序的行为在不同的VM上可能根本不同。如果只需要线程之间的交互通信，而不需要互斥，volatile修饰符就是一种可以接受的同步形式，但要正确地使用它可能需要一些技巧。
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
