并发实战 之「 对象的共享及组合」
对象的共享
我们曾说过，要编写正确的并发程序，关键问题在于：在访问共享的可变状态时需要进行正常的管理。
public class NoVisibility {
private static boolean ready;
private static int number;
public static class ReaderThread extends Thread {
public void run() {
while (!ready) {
Thread.yield();
}
System.out.println(number);
}
}
public static void main(String[] args) {
new ReaderThread().start();
number = 20151120;
ready = true;
}
}如上述代码所示，该程序可能会持续循环下去，因为读线程可能永远都看不到ready的值。甚至NoVisibility可能会输出0，因此读线程可能看到了写入ready的值，但却没有看到之后写入number的值，这种现象被称为“重排序”。只要在某个线程中无法检测到重排序情况（即使在其他线程中可以很明显地看到该线程中的重排序），那么就无法确保线程中的操作将按照程序中指定的顺序来执行。在没有同步的情况下，编译器、处理器以及运行时等都可能对操作的执行顺序进行一些意想不到的的调整。在缺乏足够同步的多线程中，要想对内存操作的执行顺序进行判断，几乎无法得出正确的结论。
Java 内存模型要求，变量的读取操作和写入操作都必须是原子操作，但对于非volatile类型的long和double变量，JVM 运行将 64 位的读操作或写操作分解为两个 32 位的操作。当读取一个非volatile类型的long变量时，如果对该变量的读操作和写操作在不同的线程中执行，那么可能会读取到某个值的高 32 位和另一个值的低 32 位。因此，即使不考虑失效数据问题，在多线程程序中使用共享且可变的long和double等类型的变量也是不安全的，除非用关键字volatile来声明它们，或者用锁保护起来。加锁的含义不仅仅局限于互斥行为，还包括内存可见性。为了确保所有线程都能看到共享变量的最新值，所有执行读操作或者写操作的线程都必须在同一个锁上同步。
Java 语言提供了一种稍弱的同步机制，即volatile变量，用来确保将变量的更新操作通知到其他线程。从内存可见性的角度来看，写入volatile变量相当于退出同步代码块，而读取volatile变量相当于进入同步代码块。仅当volatile变量能简化代码的实现以及对同步策略的验证时，应该使用它们。如果在验证正确性时需要对可见性进行复杂的判断，那么就不要使用volatile变量。volatile变量正确使用的方式包括：确保它们自身状态的可见性，确保它们所引用对象的状态的可见性，以及标识一些重要的程序生命周期事件的发生（例如，初始化或关闭）。加锁机制既可以确保可见性又可以确保原子性，而volatile变量只能确保可见性。当且仅当满足以下所有条件时，才应该使用volatile变量：
- 对变量的写入操作不依赖变量的当前值，或者你能确保只有单个线程更新变量的值；
- 该变量不会与其他状态变量一起纳入不变性条件中；
- 在访问变量时不需要加锁。
此外，对于服务器应用程序，无论是在开发阶段还是在测试阶段，当启动 JVM 时一定要指定-server命令行选项。server模式的 JVM 将比client模式的 JVM 进行更多的优化，例如将循环中未被修改的变量提升到循环外部，因此在开发环境（client模式的 JVM）中能正确运行的代码，可能会在部署环境（server模式的 JVM）中运行失败。例如，
volatile boolean asleep;
......
while (!asleep) {
countSomeSheep();
}在上面的程序中，如果我们没有将asleep变量声明为volatile类型，那么server模式的 JVM 会将asleep的判断条件提升到循环体外部（这将导致一个无限循环），但client模式的 JVM 不会这么做。在解决开发环境中出现无限循环问题时，解决这个问题的开销远远小于解决在应用环境出现无限循环的开销。
"发布"一个对象的意思是指，使对象能够在当前作用域之外的代码中使用；当某个不应该发布的对象被发布时，这种情况就被称为“逸出”。当发布一个对象时，在该对象的非私有域中引用的所有对象同样会被发布。当把一个对象传递给某个外部方法时，就相当于发布了这个对象。如果this引用在构造过程中逸出，那么这种现象就被认为是“不正确构造”。当对象在其构造函数中创建一个线程时，无论是显式创建（通过将它传给构造函数）还是隐式创建（由于Thread或Runnable是该对象的一个内部类），this引用都会被新创建的线程共享。在构造函数中调用一个可改写的实例方法时（既不是私有方法，也不是终结方法），同样会导致this引用在构造过程中逸出。
线程封闭
当访问共享的可变数据时，通常需要使用同步。一种避免使用同步的方式就是不共享数据。如果仅在单线程内访问数据，就不需要同步。这种技术被为线程封闭（Thred Confinement），它是实现线程安全性的最简单方式之一。当某个对象封闭在一个线程中时，这种用法将自动实现线程安全性，即使被封闭的对象本身不是线程安全的。常见的线程封闭方式有三种，分别为：
Ad-hoc线程封闭：指维护线程封闭性的职责完全由程序来承担。该方式是非常脆弱的，因此没有任何一种语言的特性，例如可见性修饰符或局部变量，能将对象封闭到目标线程上。事实上，对线程封闭对象的引用通常保存在公有变量中。- 栈封闭：它是线程封闭的一种特例，在栈封闭中，只能通过局部变量才能访问对象。局部变量的固有属性之一就是封闭在执行线程之中，它们位于执行线程的栈中，其他线程无法访问这个栈。栈封闭比
Ad-hoc线程封闭更易于维护，也更加健壮。 ThreadLocal类：维持线程封闭性的一种更规范方法是使用ThreadLocal，这个类能使线程中的某个值与保存值的对象关联起来。ThreadLocal提供了get和set等访问接口或方法，这些方法为每个使用该变量的线程都存有一份独立的副本，因此get总是返回由当前执行线程在调用set时设置的最新值。ThreadLocal对象通常用于防止对可变的单实例变量或全局变量进行共享。
不变性
如果某个对象在被创建后其状态就不能被修改，那么这个对象就被称为不可变对象。线程安全性是不可变对象的固有属性之一，它们的不变性条件是由构造函数创建的，只要它们的状态不可变，那么这些不变性条件就能得以维持。不可变对象不等于将对象中所有的域都声明为final类型，即使对象中所有的域都是final类型的，这个对象也仍然可能是可变的，因为在final类型的域中可以保持对可变对象的引用。当满足以下条件时，对象才是不可变的：
- 对象创建以后其状态就不能修改；
- 对象的所有域都是
final类型； - 对象是正确创建的，在对象的创建期间
this引用没有逸出。
final类型的域是不能修改的，但如果final域所引用的对象是可变的，那么这些被引用的对象是可以修改的。然而，在 Java 内存模型中，final域还有着特殊的语义，final域能确保初始化过程的安全性，从而可以不受限制地访问不可变对象，并在共享这些对象时无须同步。正如“除非需要更高的可见性，否则应将所有的域都声明为私有域”是一个良好的编程习惯，“除非需要某个域是可变的，否则应将其声明为final域”也是一个良好的编程习惯。
安全发布
任何线程都可以不需要额外同步的情况下安全地访问不可变对象，即使在发布这些对象时没有使用同步。但是对于可变对象，则必须通过安全的方式来发布，这意味着在发布和使用该对象的线程时都必须使用同步。要安全地发布一个对象，对象的引用以及对象的状态必须同时对其他线程可见。一个正确构造的对象可以通过以下方式来安全地发布：
- 在静态初始化函数中初始化一个对象引用；
- 将对象的引用保存到
volatile类型的域或者AtomicReferance对象中； - 将对象的引用保存到某个正确构造对象的
final类型域中； - 将对象的引用保存到一个由锁保护的域中。
如果对象从技术上来看是可变的，但其状态在发布后不会再改变，那么把这种对象称为“事实不可变对象”。在没有额外的同步的情况下，任何线程都可以安全地使用被安全发布的事实不可变对象。如果对象在构造后可以修改，那么安全发布只能确保“发布当时”状态的可见性。对于可变对象，不仅在发布对象时需要使用同步，而且在每次对象访问的时同样需要使用同步来确保后续修改操作的可见性。对象发布的需求取决于它的可变性：
- 不可变对象可以通过任意机制来发布；
- 事实不可变对象必须通过安全方式来发布；
- 可变对象对象通过安全方式发布，并且必须是线程安全的或者由某个锁保护起来。
在并发程序中使用和共享对象，可以使用一些使用的策略，包括：
- 线程封闭：线程封闭的对象只能由一个线程拥有，对象被封闭在该线程中，并且只能由这个线程修改。
- 只读共享：在没有额外同步的情况下，共享的只读对象可以由多个线程并发访问，但任何线程都不能修改它，共享的只读对象包括不可变对象和事实不可变对象。
- 线程安全共享：线程安全的对象在其内部实现同步，因此多个线程可以通过对象的公有接口来进行访问而不需要进一步的同步。
- 保护对象：被保护的对象只能通过持有特定的锁来访问，保护对象包括封装在其他线程安全对象中的对象以及已发布的并且由某个特定锁保护的对象。
对象的组合
通过使用封闭技术，可以使得在不对整个程序进行分析的情况下就可以判断一个类是否是线程安全的。在设计线程安全类的过程中，需要包含以下三个基本要素：
- 找出构成对象状态的所有变量；
- 找出约束状态变量的不变性条件；
- 建立对象状态的并发访问管理策略。
由于不变性条件以及后验条件在状态转换上施加了各种约束，因此就需要额外的同步与封装。在类中也可以包含同时约束多个状态变量的不变性条件。如果在一个不变性条件中包含多个变量，那么在执行任何访问相关变量的操作时，都必须持有保护这些变量的锁。
实例封闭
将数据封装在对象内部，可以将数据的访问权限限制在对象的方法上，从而更容易确保线程在访问数据时总能持有正确的锁。被封闭对象一定不能超出它们的既定的作用域。对象可以封闭在类的一个实例，例如作为类的一个私有成员中；或者封闭在某个作用域内，例如作为一个局部变量；再或者封闭在线程内，例如在某个线程中将对象从一个方法传递到另一个方法，而不是在多个线程之间共享该对象。
// 线程安全
public class PersonSet {
private final Set<Person> mySet = new HashSet<Person>();
public synchronized void addPerson(Person p) {
mySet.add(p);
}
public synchronized boolean containsPerson(Person p) {
return mySet.contains(p);
}
}在 Java 平台的类库中还有很多线程封闭的示例，其中有些类的唯一用途就是将非线程安全的类转化为线程安全的类，如Conllections.synchronizedSet()，因此上述的代码可以修改为：
// 线程安全
public class PersonSet {
private final Set<Person> mySet = new HashSet<Person>();
private final Set<Person> safeMySet = Collections.synchronizedSet(mySet);
public void addPerson(Person p) {
safeMySet.add(p);
}
public boolean containsPerson(Person p) {
return safeMySet.contains(p);
}
}只要包装器对象拥有对底层容器对象的唯一引用（即把底层容器对象封闭在包装器中），那么它就是线程安全的。封闭机制更易于构造线程安全的类，因为当封闭类的状态时，在分析类的线程安全性时就无须检查整个程序。
如果一个类是由多个独立且线程安全的状态变量组成，并且在所有的操作中都不包含无效状态转换，那么可以将线程安全性委托给底层的状态变量。如果一个状态变量是线程安全的，并且没有任何不变性条件来约束它的值，在变量的操作上也不存在任何不允许的状态转换，那么就可以安全地发布这个变量。
组合
当为现有的类添加一个原子操作时，有一个很好的方式，那就是：组合。
// 线程安全
public class ImprovedList<T> implements List<T> {
private final List<T> list;
public ImprovedList(List<T> list) {
this.list = list;
}
public synchronized boolean putIfAbsent(T x) {
boolean contains = list.contains(x);
if (contains) {
list.add(x);
}
return !contains;
}
// ......按照类似的方式委托List的其他方法
}如上述代码所示，ImprovedList通过将List对象的操作委托给底层的List实例实现List的操作，同时还添加了一个原子的putIfAbsent()方法。ImprovedList通过自身的内置锁增加了一层额外的加锁。它并不关心底层的List是否是线程安全的，即使List不是线程安全的或者修改了它的加锁实现，ImprovedList也会提供一致的加锁机制来实现线程安全性。虽然额外的同步层可能导致轻微的性能损失，但与模拟另一个对象的加锁策略相比，ImprovedList更为健壮。事实上，我们使用了 Java 监视器模式来封装现有的List，并且只要在类中拥有指向底层List的唯一外部引用，就能确保线程安全性。