如何扩展线程安全的类

为什么80%的码农都做不了架构师？>>>   

Java类库包含许多有用的“基础模块”类。通常，我们应该优先选择重用这些现有的类而不是创建新的类：重用能降低开发工作量、开发风险（因为现有的类都已经通过测试）以及维护成本。有时候，某个现有的线程安全类能支持我们需要的所有操作，但更多时候，现有的类智能支持大部分的操作，此时就需要在不破坏线程安全性的情况下添加一个新的操作。

例如，假设需要一个线程安全的链表，它需要提供一个原子的“若没有则添加（putIfAbsent）”的操作。同步的List类已经实现了大部分的功能，我们可以根据它提供的contains方法和add方法来构造一个“若没有则添加”。由于这个类必须是线程安全的，因此就隐含的增加了另一个需求，即“若没有则添加”这个操作必须是原子操作。这意味着如果在链表中没有包含对象X，那么在执行两次“若没有则添加”X后，在容器中只能包含一个X对象。然而，如果“若没有则添加”操作不是也uanzi操作，那么在某些执行情况下，有两个线程都将看到X不在容器中，并且都执行了添加X的操作，从而使容器包含两个相同的对象。

• 修改类

要添加一个新的原子操作，最安全的方法是修改原始的类，但这通常无法做到，因为你可能无法访问或修改类的源代码。要想修改原始的类，就需要理解代码中的同步策略，这样增加的功能才能与原有的设计保持一致。如果直接将新方法添加到类中，那么意味着实现同步策略的所有代码任然处于一个源代码文件中，从而更容易理解与维护。

• 扩展类

另一种方法是扩展这个类（假定在设计这个类时考虑了可扩展性，即类不是final修饰的）。下面的代码中的BetterVector对Vector类进行了扩展，并添加了一个新方法putIfAbsent。扩展Vector很简单，但并非所有的类都像Vector那样将状态向子类公开，因此也就不适合采用这种方法。

public class BetterVector<E> extends Vector<E> {
	public synchronized boolean putIfAbsent(E x) {
		boolean absent = !contains(x);
		if (absent) {
			add(x);
		}
		return absent;
	}
}

“扩展”方法比直接将代码添加到类中更加脆弱，因为现在的同步策略实现被分不到多个单独维护的源代码文件中。如果底层的类改变了同步策略并选择了不同的锁来保护它的状态变量，那么子类会被破坏，因为在同步策略改变后它无法再使用正确的锁来控制对基类状态的并发访问。（在Vector的规范中定义了它的同步策略，因此BetterVector不存在这个问题）

• 客户端加锁

对于由Collections.synchronizedList封装的ArrayList，上述两种方法都行不通，因为客户端代码并不知道在同步封装器工厂中返回的List对象的类型。第三种策略是扩展类的功能，但并不是扩展类本身，而是将扩展代码放入一个“辅助类”中。下面的代码实现了一个包含“若没有则添加”操作的辅助类，用于对线程安全的List进行操作看，但其中的代码是错误的：

public class ListHelper<E> {
	public List<E> list = Collections.synchronizedList(new ArrayList<E>());
	public synchronized boolean putIfAbsent(E x) {
		boolean absent = !list.contains(x);
		if (absent) {
			list.add(x);
		}
		return absent;
	}
}

为什么这种方式不能实现线程安全性？毕竟putIfAbsent已经声明为synchronized类型的方法，对不对？问题在于在错误的锁上进行了同步。无论List使用哪一个锁来保护它自己的状态，可以确定的是，这个锁并不是ListHelper上的锁。ListHelper只是带来了同步的假象，尽管所有的链表操作都被声明为synchronized，但却使用了不同的锁，这意味着putIfAbsent相对于List的其他操作来说并不是原子的，因此就无法确保当putIfAbsent执行时，另一个线程不会修改链表。

要想使这个方法能正确执行，必须使List在客户端实现加锁或外部加锁时使用的是同一个锁。客户端加锁是指：对于使用某个对象X的客户端代码，使用X本身用于保护其状态的锁来保护这段客户代码。要使用客户端加锁，你必须知道对象X使用的是哪一个锁。

在Vector和同步封装器类（Collections.synchronized[List/Map/Set]）的文档中指出，它们通过使用Vector或封装容器内置锁来支持客户端加锁。

public class ListHelper<E> {
	public List<E> list = Collections.synchronizedList(new ArrayList<E>());
	public boolean putIfAbsent(E x) {
		synchronized(list) {
			boolean absent = !list.contains(x);
			if (absent) {
				list.add(x);
			}
			return absent;
		}
	}
}

通过添加一个原子操作来扩展类是脆弱的，因为它将类的加锁代码分布到多个类中。然而，客户端加锁却更加脆弱，因为它将类C的加锁代码放到与C完全无关的其他类中。当在那些并不承诺遵循加锁策略的类上使用客户端加锁时，要特别小心。

客户端加锁机制与扩展类机制有许多共同点，二者都是将派生类的行为与积累的实现耦合在一起。和扩展会破坏实现的封装性一样，客户端加锁同样会破坏同步策略的封装性。

• 组合（推荐）

当为现有的类添加一个原子操作时，还有一种更好的方法：组合（Composition）。下面的程序中的ImprovedList通过将List对象的操作委托给底层List实力来实现，同时还添加了一个原子的putIfAbsent方法（与Collections.synchronizedList和其他容器封装器一样，ImprovedList假设把某个链表对象传给构造函数以后，客户代码不会再直接使用这个对象，而只能通过ImprovedList来访问它）。

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 absent = !list.contains(x);
		if (absent) {
			list.add(x);
		}
		return absent;
	}
	//...按照类似的方式将ImprovedList的其他方法实现委托给List
}

ImprovedList通过自身的内置锁增加了一层额外的锁。它并不关心底层的List是否是线程安全的，及时List不是线程安全的或者在其后续版本中修改了它的加锁实现，ImprovedList也会提供一直的加锁机制来实现线程安全性。虽然额外的同步层可能导致轻微的性能损失，但与模拟另一个对象的加锁策略相比，ImprovedList更为健壮。

转载于:https://my.oschina.net/itblog/blog/774629