4.3.1。示例：使用委派的车辆跟踪器
作为委派的更实质性示例，让我们构造一个委派给线程安全类的Vehicle Tracker版本。我们将位置存储在Map中，因此我们从线程安全Map实现开始ConcurrentHashMap。我们还使用一个不变的Point类而不是来存储位置MutablePoint，如清单4.6所示。
清单4.6。DelegatingVehicleTracker使用的不可变Point类。
class Point{
public final int x, y;
public Point() {
this.x=0; this.y=0;
}
public Point(int x, int y) {
this.x = x;
this.y = y;
}
}
Point是线程安全的，因为它是不可变的。不变值可以自由共享和发布，因此我们在返回它们时不再需要复制位置。
DelegatingVehicleTracker清单4.7中没有使用任何显式同步；所有对状态的访问都由管理ConcurrentHashMap，并且Map的所有键和值都是不可变的。
清单4.7。将线程安全委托给ConcurrentHashMap。
public class DelegatingVehicleTracker {
private final ConcurrentMap<String, Point> locations;
private final Map<String, Point> unmodifiableMap;
public DelegatingVehicleTracker(Map<String, Point> points) {
this.locations = new ConcurrentHashMap<String, Point>(points);
this.unmodifiableMap = Collections.unmodifiableMap(locations);
}
public Map<String, Point> getLocations(){
return this.unmodifiableMap; // User cannot update point(x,y) as Point is immutable
}
public Point getLocation(String id) {
return locations.get(id);
}
public void setLocation(String id, int x, int y) {
if(locations.replace(id, new Point(x, y)) == null) {
throw new IllegalArgumentException("invalid vehicle name: " + id);
}
}
}
如果我们使用原始MutablePoint类而不是Point，那么将通过getLocations发布对线程安全的可变状态的引用来破坏封装。注意，我们已经稍微改变了车辆跟踪器类的行为；监控器版本返回位置的快照，而委派版本返回车辆位置的不可修改但“实时”的视图。这意味着，如果线程A调用getLocations而线程B随后修改了某些点的位置，则这些更改将反映在返回给线程A的Map中。
4.3.2。独立状态变量
只要这些基础状态变量是独立的，我们还可以将线程安全委托给多个基础状态变量，这意味着复合类不强加涉及多个状态变量的任何不变式。
VisualComponent清单4.9中的图形组件是允许客户端注册鼠标和击键事件的侦听器的图形组件。它维护每种类型的已注册侦听器列表，以便在事件发生时可以调用适当的侦听器。但是，鼠标侦听器和按键侦听器的集合之间没有任何关系。两者是独立的，因此VisualComponent可以将其线程安全义务委派给两个基础线程安全列表。
清单4.9。将线程安全委托给多个基础状态变量。
public class VisualComponent {
private final List<KeyListener> keyListeners
= new CopyOnWriteArrayList<KeyListener>();
private final List<MouseListener> mouseListeners
= new CopyOnWriteArrayList<MouseListener>();
public void addKeyListener(KeyListener listener) {
keyListeners.add(listener);
}
public void addMouseListener(MouseListener listener) {
mouseListeners.add(listener);
}
public void removeKeyListener(KeyListener listener) {
keyListeners.remove(listener);
}
public void removeMouseListener(MouseListener listener) {
mouseListeners.remove(listener);
}
}
VisualComponent使用CopyOnWriteArrayList存储每个侦听器列表；这是一个线程安全的List实现，特别适合于管理侦听器列表（请参阅第5.2.3节）。每个列表都是线程安全的，并且由于没有将一个状态与另一个状态耦合的约束，因此VisualComponent可以将其线程安全职责委派给基础对象mouseListeners和keyListeners对象。
4.3.3。委托失败时
大多数复合类都不像VisualComponent：它们具有将其组件状态变量关联的不变式。NumberRange清单4.10中的示例使用两个AtomicIntegers来管理其状态，但是施加了一个附加约束-第一个数字小于或等于第二个。
清单4.10 无法充分保护其不变式的数字范围类。不要这样
public class NumberRange {
// INVARIANT: lower <= upper
private final AtomicInteger lower = new AtomicInteger(0);
private final AtomicInteger upper = new AtomicInteger(0);
public void setLower(int i) {
//Warning - unsafe check-then-act
if(i > upper.get()) {
throw new IllegalArgumentException(
"Can't set lower to " + i + " > upper ");
}
lower.set(i);
}
public void setUpper(int i) {
//Warning - unsafe check-then-act
if(i < lower.get()) {
throw new IllegalArgumentException(
"Can't set upper to " + i + " < lower ");
}
upper.set(i);
}
public boolean isInRange(int i){
return (i >= lower.get() && i <= upper.get());
}
}
NumberRange是不是线程安全的 ; 它不保留约束上下限的不变式。该setLower和setUpper方法试图尊重这一不变的，但这样做不好。这两个setLower和setUpper是检查当时的行为序列，但他们不使用足够的锁定，使它们的原子。如果数字范围保持（0，10），并且一个线程调用，setLower(5)而另一个线程调用setUpper(4)，则在一些不幸的时间安排下，两个线程都将通过设置器中的检查，并且将应用两个修改。结果是该范围现在保持（5，4）- 无效状态。因此，虽然底层的AtomicIntegers是线程安全的，但复合类不是。因为基础状态变量lower和upper它们不是独立的，NumberRange不能简单地将线程安全委托给其线程安全状态变量。
NumberRange通过使用锁来保持其不变性，例如使用通用锁保护下部和上部，可以使线程安全。它还必须避免上下发布，以防止客户端颠覆其不变式。
如果一个类具有复合动作，NumberRange那么，单独委托又不是线程安全的合适方法。在这些情况下，该类必须提供自己的锁定以确保复合动作是原子的，除非整个复合动作也可以委托给基础状态变量。
如果一个类由多个独立的线程安全状态变量组成，并且不具有任何具有无效状态转换的操作，则它可以将线程安全委托给基础状态变量。