Java 类库中包括很多实用的”基础模块“类。通常，我们应该优先选择重用这些现有的类而不是创建新的类。：重用能减少开发工作量、开发风险（由于现有类都已经通过測试）以及维护成本。有时候，某个线程安全类能支持我们须要的全部操作，但很多其它的时候，现有的类仅仅能支持大部分的操作，此时就须要在不破坏线程安全的情况下加入一个新的操作。
如果我们须要一个线程安全的链表，他须要提供一个原子的”若没有则加入（Put-If-Absent）“的操作。同步的 List 类已经实现了大部分的功能，我们能够依据它提供的 contains 方法和 add 方法构造一个实现。
能够有四种方法来实现这个原子操作。
第一种方法，也是最安全的方法，便是改动原始类。
但这一般是无法做到的，由于你可能无法訪问或改动类的源码。要想改动原始的类，就须要深刻理解代码中的同步策略，这样添加的功能才干与原有的设计保持一致。假设直接将新方法加入到类中，那么意味着实现同步策略的全部代码仍然处于一个源码文件里，从而更easy理解与维护。
另外一种方法，能够扩展（继承）这个类—-假如原始类在设计的时候时考虑到了它的可扩展性。
比如，我们能够设计一个 BetterVector 对 Vector 进行扩展，并加入了一个新方法 putIfAbsent。
public class BetterVector<E> extends Vector<E>{
public synchronized boolean putIfAbsent(E x){
boolean absent = !contains(x);
if(absent)add(x);
return absent;
}
}
扩展 Vector 非常easy，但并不是全部的类都像 Vector 那样将状态向子类公开，因此也就不适合採用这样的方法。
”扩展“方法比較脆弱，主要原因是 同步策略的实现被分离到了多个源码文件里，假设底层类改变了同步策略，更改了不同的锁来保护状态，那么子类便会被破坏。
第三种方法，使用辅助类，实现client加锁机制。
对于某些类，比方 Collections.synchronizedList 封装的 ArrayList ， 前两种方法都行不通，由于客户代码不知道在同步封装器工厂方法中返回的 List 对象的类型。这时候採用client加锁的方式，将扩展代码放到一个”辅助类“中。
于是我们非常自然的就写出 ListHelper 辅助类。
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 ，可是它却是在 ListHelper 上加锁，而 List 却是用自己或内部对象的锁。 ListHelper 仅仅是带来了同步的假象，
在 Vector 和同步封装器类的文档中指出，他们是通过 Vector 或封装容器内部锁来支持client加锁。以下我们给出正确的client加锁。
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;}
}
}
通过加入一个原子操作来扩展类是脆弱的，由于它将类的加锁代码分布到多个类中。然而，client加锁却更加脆弱，由于它将类的加锁代码放到与其全然无关的其它类中。
第四种方法，使用组合（Composition）的方式。
public class ImprovedList<T> implements List<T> {
public 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;
}
//...依照相似的方式托付List的其它方法
}
ImprovedList 通过自身的内置锁添加了一层额外的加锁。它并不关心底层的 List 是否是线程安全的，即使 List 不是线程安全的或者改动了它的枷锁方式，Improved 也会提供一致的加锁机制来实现线程安全性。尽管额外的同步层可能导致轻微的性能损失，但与模拟还有一个对象的加锁策略相比，ImprovedList 更为健壮。其实，我们使用了 Java 监视器模式来封装现有 List ，而且仅仅要在类中拥有指向底层 List 的为意外不引用，就能确保线程安全性。