本文阅读大概需要18分钟。
这个题目主要考查同步容器相关的问题。
在Java多线程开发中，往往需要java中常用的容器作为共享资源来使用，如Array、List、Hashmap、Set等。但是基本的容器在多线程下进行并发操作是有问题，需要进行加锁才能保证多线程共享容器的线程安全（Thread Safe）。为了简化java多线程开发，JDK中提供了一些线程安全容器，使得程序员在开发多线程应用时，可以将更多的精力放在程序逻辑上，而不是错综复杂的锁处理上。但JDK中不同的并发容器类，拥有不同的性质和应用场景，这里我们就来分析一下三种线程安全的并发容器：ConcurrentHashMap、SychronizedMap和CopyOnWriteArrayList。
一三种容器的并发说明
首先说明一下这三种容器代表的是三类容器，我们这里只讨论这三类容器在应对并发处理上区别，并不讨论容器的数据结构区别，例如ConcurrentHashMap和ConcurrentLinkedQueue是一类容器，SychronizedMap、SynchronizedList和SynchronizedSet是一类容器。在同一类并发容器中，其同步处理策略基本上是相同的，我们在掌握其中一种容器并法特性后，便可掌握了这一类的并发容器的特性，只需在实际应用中挑选合适的数据结构即可。
二SychronizedMap
SychronizedMap是Collections包提供的一种构造安全Map容器的方法，通过静态方法Collections.synchronizedMap()便可构造一个安全容器。我们通过源码来看一下Collections是如何构造安全容器的，下面是SynchronizedMap的实现代码(JDK8)：
private static class SynchronizedMap<K,V> implements Map<K,V>, Serializable { private final Map<K,V> m; // Backing Map final Object mutex; // Object on which to synchronize SynchronizedMap(Map<K,V> m) { this.m = Objects.requireNonNull(m); mutex = this; } public int size() { synchronized (mutex) {return m.size();} } public boolean isEmpty() { synchronized (mutex) {return m.isEmpty();} } public V get(Object key) { synchronized (mutex) {return m.get(key);} } public V put(K key, V value) { synchronized (mutex) {return m.put(key, value);} } ... \\这里省略 }
我们可以看到SynchronizedMap使用synchronized对Map的所有操作都进行了加锁，从而保证了Map的线程安全性。SynchronizedMap虽然通过加锁保证了Map的线程安全性，但是整个Map只使用了一把独占锁，会造成了同一时间只有一个线程可以获取锁，对Map进行操作。这样Map的并发性就会很差，换句话说SynchronizedMap的并发量其实只有1。为了解决这样的问题，java并发大师Doug Lea开发了性能更好的ConcurrentHashMap类。
三concurrentHashMap
为了避免在多线程环境下竞争一把锁而造成的性能瓶颈问题，ConcurrentHashMap使用了锁分段技术。ConcurrentHashMap将容器中的数据进行了分段（segment），并且每一个段拥有一把锁（ReentrantLock），这样只有多线程在同时访问到同一数据段中的元素（HashEntry）时，才会存在锁竞争问题，这样就大大减少了线程阻塞在同一把锁的概率，从而提高了性能。下图便是ConcurrentHashMap的结构图：
在JDK 7中Segment类的实现如下：
static class Segment<K,V> extends ReentrantLock implements Serializable { ... }
可以看出Segment继承了ReentrantLock重入锁，可以当作锁来用，因此对于HashEntry的同步操作都依赖于其对应的段的Segment锁。这里需要说明一下，由于HashMap在JDK8中有重大改变，增加了红黑树，其对应的ConcurrentHashMap也不再使用段锁机制来保证容器的线程安全了。在JDK 8中关于Segment添加了这样的说明：
/* Stripped-down version of helper class used in previous version,declared for the sake of serialization compatibility*/
也就是Segment类的声明只为之前版本序列化兼容性操作，虽然JDK8不再使用段锁机制，但是作者认为段锁机制是一种值得我们学习的并发控制思想，在我们的实际开发中，常常不考虑程序并发性能，遇到多线程就上synchronized锁，从头锁到尾，效率非常低下，这样的代码可以说是伪多线程代码，说必定还不如单线程的性能高（毕竟线程切换也是消耗性能的），因此大师级的并发实现必然很值得我们学习。在JDK8中的ConcurrentHashMap是使用了synchronized对Node（树节点）进行加锁操作，这里就不深入进行讨论了，只需读者记住JDK8已经重新实现了ConcurrentHashMap，如果作者以后有机会写HashMap或者红黑树相关的博文时，会深入分析ConcurrentHashMap的实现的。
四CopyOnWriteArrayList
Copy-On-Write写时复制，这又是一种提高系统效率的编程思想。其思想是，在程序正常运行时所有读操作，都基于同一容器进行读操作，在容器进行写操作时，不是通过加锁来控制线程的写锁获取，而是先将容器完全复制出来一份，在新的容器上进行写操作，最后将旧容器的引用指向新容器，这样就完成了新容器的写操作。CopyOnWrite容器与读写锁（ReentrantReadWriteLock）的相同性质，进行了读写区别对待，只在写时加锁，从而提高了容器的性能。CopyOnWriteArrayList.set()实现如下（JDK8）：
public E set(int index, E element) { final ReentrantLock lock = this.lock; lock.lock(); try { Object[] elements = getArray(); E oldValue = get(elements, index); if (oldValue != element) { int len = elements.length; Object[] newElements = Arrays.copyOf(elements, len); newElements[index] = element; setArray(newElements); } else { // Not quite a no-op; ensures volatile write semantics setArray(elements); } return oldValue; } finally { lock.unlock(); } }
从set()方法的实现中，可以发现在更改CopyOnWriteArrayList中的元素时，CopyOnWriteArrayList会将原数组elements进行完全复制，并且更新元素是在新生成的newElements数组的上进行更新，最后再通过setArray()方法将新数组赋值给原数组的引用。而在CopyOnWriteArrayList的读操作中，并没有加锁：
private E get(Object[] a, int index) { return (E) a[index]; }
通过上述分析，我们可以总结出CopyOnWrite类容器具有以下性质（优缺点）：
- 读操作没有加锁,读操作不会存在线程阻塞等待现象。
- 写操作会复制整个容器，有可能造成内存大幅增长，使用不当会导致java虚拟机频繁FullGC()。
- 读操作不能立即可见。由于写操作是在新数组上进行的，因此新元素不可能对在旧数组上进行读操作的线程可见。
因此，CopyOnWrite在实际开发中，适合在读操作频繁，容器元素稳定的生产环境中使用，并且一定要注意容器大小的控制，频繁的写操作会造成大内存的频繁申请与释放，有可能因此触发java虚拟机的stop-the-world。
本文分析了三种类型的并发容器，在实际使用中如果不是JDK版本的限制，请CucurrentHashMap来替代SychronizedMap。而CopyOnWrite类容器则一般用在容器较为稳定，读操作远比写操作频繁的场景中。
此外说句题外话，我们在学习使用这些并发容器的过程中，不因仅仅学习其用法，更应该通过学习其大师级的设计思想，以及实现方式，来掌握同步控制的技巧，做到触类旁通，举一反三。
