发奋忘食，乐以忘优，不知老之将至。———《论语》
前面几篇已经介绍了关于线程安全和同步的相关知识，那么有了这些概念，我们就可以开始着手设计线程安全的类。本文将介绍构建线程安全类的几个方法，并说明他的区别。
我要讲的这几个构建线程安全类的方式是：
- 实例封闭。
- 线程安全性的委托。
- 现有的线程安全类添加功能。
另外，在设计线程安全类的过程中，我们需要考虑下面三个基本要素，遵循这三个步骤：
- 找出构成对象状态的所有变量。
- 找出约束状态变量的不变性条件。
- 建立对象状态的并发访问策略。
以上，就是这篇文章主要讲解的内容，下面章节分三个构建方法逐步展开说明，逐个分析，并附上自己测试过的实例代码，确保这篇文章分享的内容是经过验证的。
实例封闭
意思是将数据封装在对象内部，它将数据的访问限制在对象的方法上，从而更容易确保线程在访问数据时总能持有正确的锁。当一个非线程安全对象被封装到另一对象中时，能够访问被封装对象的所有代码路径都是已知的。这和在整个程序中直接访问非线程对象相比，更易于对代码进行分析。下面代码清单就是一个实例封闭的例子：
import java.util.ArrayList;
//ThreadSafe
public class PointList{
//非线程安全对象 myList
private final ArrayList<SafePoint> myList = new ArrayList<SafePoint>();
//所有访问 myList 的方法都是用同步锁，确保线程安全
public synchronized void addPoint(SafePoint p) {
myList.add(p);
}
//所有访问 myList 的方法都是用同步锁，确保线程安全
public synchronized boolean containsPoint(SafePoint p) {
return myList.contains(p);
}
//所有访问 myList 的方法都是用同步锁，确保线程安全
//发布SafePoint
public synchronized SafePoint getPoint(int i) {
return myList.get(i);
}
//ThreadSafe(可发布的可变线程安全对象)
class SafePoint{
private int x;
private int y;
private SafePoint(int[] a) {this(a[0], a[1]);}
public SafePoint(SafePoint p) {this(p.get());}
public SafePoint(int x, int y) {
this.x = x;
this.y = y;
}
//使用同步锁，确保线程安全
public synchronized int[] get() {
return new int[] {x, y};
}
//使用同步锁，确保线程安全
public synchronized void set(int x, int y) {
this.x = x;
this.y = y;
}
}
}
PointList 的状态由 ArrayList 来管理，但是 ArrayList 并非线程安全的。由于 ArrayList 私有并且不会逸出，因此 ArrayList 被封闭在 PointList 中。唯一能够访问 ArrayList 的路径都上同步锁了，也就是说 ArrayList 的状态完全有 PointList 内置锁保护，因而 PointList 是一个线程安全的类。Point 类的安全性放到后面讨论。
从这里例子可以看出，实例封闭可以非常简单的构建出线程安全的类。封闭机制更易于构造线程安全的类，因为当封闭类的状态时，在分析类的线程安全性时就无需检查整个程序。当然，如果将一个本该封闭的对象发布出去，那么也会破坏封闭性。
线程安全性的委托
如果类中的各个状态已经是线程安全的，那么是否需要再增加一个线程安全层的封装呢？
具体问题具体分析，这种需要视情况而定。
1） 如果各个状态变量是相互独立的并且互不依赖，并且没有复合操作，那么可以将线程安全性委托给底层的状态变量。如将安全性委托给 value：
import java.util.concurrent.atomic.AtomicInteger;
public class SafeSequene{
private value = new AtomicInteger(0);
//返回一个唯一的数值
public synchronized int getNext(){
return value.incrementAndGet();
}
}
2） 如果各个状态变量之间存在依赖关系，并且存在复合操作，那么是非线程安全的。来看下面一个例子，NumberRange 这个类的各个状态组成部分都是线程安全的，但是存在状态之间的依赖关系，并非互相独立，所以也是非线程安全的。
import java.util.concurrent.atomic.AtomicInteger;
public class NumberRange{
//不变性条件：lower <= upper
private final AtomicInteger lower = new AtomicInteger(0);//线程安全类
private final AtomicInteger upper = new AtomicInteger(0);//线程安全类
private static boolean flag = true;
private static volatile boolean stopAllThread = false; //检测到无效状态，停止所有线程并输出，此时lower > upper
private static int count = 3; //非线程安全，但是不必理会，不影响我们测试
//检查然后更新
public void setLower(int i) {
if(i <= upper.get()) { //lower依赖upper的值，有可能upper的值已经失效
lower.set(i);
}
}
//检查然后更新
public void setUpper(int i) {
if(i >= lower.get()) { //upper依赖lower的值，有可能lower的值已经失效
upper.set(i);
}
}
public static void main(String[] args) {
NumberRange nr = new NumberRange();
while(stopAllThread == false) {
for(int i = 0; i < 10000; i++) {
if(stopAllThread == true)
break;
new Thread(new Runnable() {
@Override
public void run() {
if(stopAllThread == true)
return;
if(flag == true)
{
flag = false;
nr.setLower(count++);
}
else {
flag = true;
nr.setUpper(count);
}
if(nr.lower.get() > nr.upper.get()) //检测到无效状态，lower > upper
{
stopAllThread = true;
System.out.println("state wrong");//打印错误信息
System.out.println("lower = " + nr.lower.get() + " upper = " + nr.upper.get());
}
}
}).start();
}
while(Thread.activeCount() > 1);
System.out.println("lower = " + nr.lower.get() + " upper = " + nr.upper.get());
}
}
}
在上面的程序中，并发的情况下我们可以检测到无效状态，即 upper 的值大于 lower 的值。这便是不满足我们的不变性条件，因为状态变量 lower 和 upper 不是彼此独立的，因此 NumberRange 不能将线程安全委托给他的线程安全状态变量。输出如下：
3） 如何安全的发布底层的状态变量？
如果一个状态变量是线程安全的，并且没有任何不变性条件来约束他的值，在变量操作上也不存在任何不允许的状态转换，那么就可以安全的发布这个变量。在示例封闭的代码清单中，SafePoint 是一个可变的且线程安全的类，我们可以安全的发布它。
现有的线程安全类添加功能
Java 的类库中，已经包含了很多线程安全的基础模块。通常，我们可以直接拿来重用，并不需要重复造轮子。重用已有的类库，可以有效降低开发的工作量，开发风险以及维护成本。下面将讲解三种方式来增加新方法，组合方式将是最优的方法。我们应当避免使用前两种方式，而所用最后一种方式。
通过继承基类添加功能（扩展类方式）
假设，我们需要对 Vector 扩展，添加一个[若没有则添加]的操作。我们想到的最直接的方法应该是修改原始类，但是通常是无法做到的，因为我们极有可能没法访问或修改类的源代码。
现在采用另一种方式，通过继承基类的方式扩展这个类并添加一个新方法 putIfAbsent。如下所示：
import java.util.Vector;
//ThreadSafe
public class BetterVector<E> extends Vector<E>{
public synchronized boolean putIfAbsent(E x) {
boolean absent = !contains(x);
if(absent)
add(x);
return absent;
}
}
这样就可以成功添加一个新的方法。然而，这比直接在基类代码增加新方法更加脆弱，因为现在的同步策略被分布到多个源码文件中。如果底层的类修改了同步策略并选择不同的锁来保护，那么子类将会失效，不能保证线程安全。
客户端加锁机制
同样，来增加一个新方法 putIfAbsent，请看下面代码：
import java.util.ArrayList;
import java.util.Collections;
import java.util.List;
public class ListHelper<E> {
public List<E> list = Collections.synchronizedList(new ArrayList<>());
//无效的同步锁
public synchronized boolean putIfAbsent(E x) {
boolean absent = !list.contains(x);
if(absent)
list.add(x);
return absent;
}
}
这种方式并不能实现线程安全,它的问题在于同步的时候使用了错误的锁。因为 List 本身用的锁肯定不是 ListHelper 上的锁，这意味着 putIfAbsent 相对于其他 List 的方法来说并不是同步的。所以看起来同步了实际上却没有什么卵用。
要使这个方法能够正确同步，必须在客户端加锁。即对于使用某个对象 X 的客户端代码，使用 X 本身用于保护其状态的锁来保护这段客户代码。要使用客户端加锁，你必须知道对象 X 使用的是哪个锁。
在 Vector 和同步封装器的文档中指出，他们通过使用 Vector 或封装器容器的内置锁来支持客户端加锁。上面代码可以改成如下：
import java.util.ArrayList;
import java.util.Collections;
import java.util.List;
public class ListHelper<E> {
public List<E> list = Collections.synchronizedList(new ArrayList<>());
public boolean putIfAbsent(E x) {
synchronized(list) {//客户端加锁
boolean absent = !list.contains(x);
if(absent)
list.add(x);
return absent;
}
}
}
客户端加锁方式是很脆弱的加锁方式，意味他将类 C 的加锁代码放到与 C 完全无关的其他类中。所以在使用客户端加锁时，需要特别小心。
客户端加锁机制和扩展类机制有许多共同点，二者都是讲派生类的行为与基类的实现耦合在一起，会破坏实现的封装性和同步策略的封装性。
组合
相比前面两种机制，这是一种更好的方法。如下所示，ImprovedList 将 List 的操作委托给底层的 List 对象，然后自己继承 List 接口的所有方法并对他们加上同步锁。
import java.util.Collection;
import java.util.Iterator;
import java.util.List;
import java.util.ListIterator;
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;
}
@Override
public synchronized boolean add(T arg0) {
list.add(arg0);
return false;
}
@Override
public synchronized void clear() {
// TODO Auto-generated method stub
list.clear();
}
//按照此同步方式实现其他方法
}
ImprovedList 增加了一层自身的内置锁，它不用关心底层的 List 是否线程安全或者底层 List 修改了他自己的加锁实现，ImprovedList 都能构提供一致的加锁机制来实现线程安全性。当然，加多一层锁会导致性能损失，但是 ImprovedList 相比前面两种方式也更加健壮。
上面就是构建安全类的所有内容，希望对你有所帮助，谢谢！
