从SynchronizedCollection说起

2019年6月15日 178次阅读

SynchronizedCollection简介

SynchronizedCollection是Collections下所有现场安全集合的父类，并发安全集合可以分为三类，一种是比较老的实现，例如vector，一种是concurrent包下的，另外一种就是SynchronizedCollection。他是通过对并发不安全的集合进行包装，使得线程安全。

实现介绍

上面也说了，他是通过对并发不安全的集合进程包装的。思想上就是加了一个object锁，然后在每个方法上加入锁的逻辑。

    static class SynchronizedCollection<E> implements Collection<E>, Serializable {
        final Collection<E> c;  // Backing Collection
        final Object mutex;     // Object on which to synchronize
        SynchronizedCollection(Collection<E> c, 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();}
        }
        public <T> T[] toArray(T[] a) {
            synchronized (mutex) {return c.toArray(a);}
        }

是不是看了实现的你也是微微一下，这里就是通过synchronized 加锁mutex。然后在代码块里执行原来的集合的方法，由于每个方法都被加上了锁，所以集合也成为了并发安全的集合。
安全性依靠的就是集合被覆写，如果没有被覆写，那么线程安全性也就不保证了。很多人也很好奇，这都是包装安全了，为啥还会这么说。
下面就展示一个例外。

        public Iterator<E> iterator() {
            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增加了功能，但是功能有更多的特性，最后反而是面向了实现类编程。
装饰者模式的好处是灵活，功能扩展方便。坏处就是功能扩展有限制，一个限制在接口，一个限制在被装饰者内部的成员变量。

点赞