题目：
请说明一下同步容器CopyOnWriteArrayList/ConcurrentHashMap/SynchronizedMap（Collections定义的内部类）的区别及它们的应用场景？
在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类容器则一般用在容器较为稳定，读操作远比写操作频繁的场景中。
此外说句题外话，我们在学习使用这些并发容器的过程中，不因仅仅学习其用法，更应该通过学习其大师级的设计思想，以及实现方式，来掌握同步控制的技巧，做到触类旁通，举一反三。
记得关注我们哦，这里全部都是干货！！！