SynchronizedCollection简介
SynchronizedCollection是Collections下所有现场安全集合的父类，并发安全集合可以分为三类，一种是比较老的实现，例如vector，一种是concurrent包下的，另外一种就是SynchronizedCollection。他是通过对并发不安全的集合进行包装，使得线程安全。
实现介绍
上面也说了，他是通过对并发不安全的集合进程包装的。思想上就是加了一个object锁，然后在每个方法上加入锁的逻辑。
static class SynchronizedCollectionimplements Collection, Serializable {
final Collectionc; // Backing Collection
final Object mutex; // Object on which to synchronize
SynchronizedCollection(Collectionc, Object mutex) {
this.c = Objects.requireNonNull(c);
this.mutex = Objects.requireNonNull(mutex);
}
....
}
SynchronizedCollection有两个成员变量，一个是被包装的集合对象c，一个是用来作为锁的对象mutex。集合对象和锁对象都可以通过构造函数传入。
大家如果看过vector的实现的话，大概明白接下来的实现手段了，就是加锁!
public int size() {
synchronized (mutex) {return c.size();}
}
public boolean isEmpty() {
synchronized (mutex) {return c.isEmpty();}
}
public boolean contains(Object o) {
synchronized (mutex) {return c.contains(o);}
}
public Object[] toArray() {
synchronized (mutex) {return c.toArray();}
}
publicT[] toArray(T[] a) {
synchronized (mutex) {return c.toArray(a);}
}
是不是看了实现的你也是微微一下，这里就是通过synchronized 加锁mutex。然后在代码块里执行原来的集合的方法，由于每个方法都被加上了锁，所以集合也成为了并发安全的集合。
安全性依靠的就是集合被覆写，如果没有被覆写，那么线程安全性也就不保证了。很多人也很好奇，这都是包装安全了，为啥还会这么说。
下面就展示一个例外。
public Iteratoriterator() {
return c.iterator(); // Must be manually synched by user!
}
iterator方法没有被覆写!也就是说使用迭代器迭代的时候，线程是不安全的，所以这个方法的也加了注释，需要用户加同步。
很多时候大家的第一反应就是给iterator加synchronized 的就可以。但是真的是这样吗?
我们来推演一下，如果在iterator方法上加锁，那么确实保证了iterator方法是线程安全的，在并发的情况下，只会有一个线程操作成功，成功获取到iterator对象。但是接下来呢，我们要拿到iterator对象进行迭代，此时如果集合有增删操作是可以的，因为iterator对象的操作完全没有锁竞争。此时迭代就会出错。
装饰者模式
SynchronizedCollection这种通过实现Collection接口，然后自己把接口的方法都实现了一遍，并且使用了组合的方式，对每个方法增加了新的功能，最后还返回接口对象，面向接口编程。这就是典型的装饰者模式。
为了增加新的功能，不断的继承接口，实现自己的新逻辑，而且对调用端屏蔽了操作。如果说在增加一个需求，就是需要一个集合操作完之后就删除一个元素。那么只要实现Collection接口，对每个方法的调用都做一个删除的操作，并且执行传入的集合对象就可以了，在生成对象的时候，不断的构造对象传入。如果功能不需要了，例如不需要线程安全的需求了，那么只要在生成对象的时候，直接去掉SynchronizedCollection就可以了。
装饰者模式的优点就是对外面向接口，对调用者屏蔽细节。然后功能拆分比较细，可以进行比较灵活的组装。
iterator的问题，其实也是装饰者模式的弊端，就是他对包装者的功能扩展是有一定限制的。他可以对他包装的对象进行扩展，但是并不能对包装对象里依赖的对象进行太多的干预。
java中装饰者模式的应用
除了上面的SynchronizedCollection。java中另外一个典型的案例就是io。
java的io是可以不停的功能扩展的。
FileInputStream是基础的字节io
InputStreamReader可以对FileInputStream进行功能扩充
BufferedReader对Reader可以再进程扩充
其实大家使用的时候的一些缺点也暴露出来了，就是功能扩充的限制问题，我们一旦装饰到BufferedReader，就不会再去使用read方法了，主要使用readLine这个功能了，其实接口并没有这个方法，所以我们使用io的时候已经不再是面向接口了，更多的是面向了具体的实现，因为在文件的场景下。接口并不能彻底抽象全部功能，他只能有共有的。
总结
java中有两个地方使用了装饰者模式，io，SynchronizedCollection。
SynchronizedCollection对每个方法进行了功能的扩充，但是对包装类里的成员变量不能控制。
io增加了功能，但是功能有更多的特性，最后反而是面向了实现类编程。
装饰者模式的好处是灵活，功能扩展方便。坏处就是功能扩展有限制，一个限制在接口，一个限制在被装饰者内部的成员变量。