引言

容器是Java基础类库中使用频率最高的一部分，Java集合包中提供了大量的容器类来帮组我们简化开发，我前面的文章中对Java集合包中的关键容器进行过一个系列的分析，但这些集合类都是非线程安全的，即在多线程的环境下，都需要其他额外的手段来保证数据的正确性，最简单的就是通过synchronized关键字将所有使用到非线程安全的容器代码全部同步执行。这种方式虽然可以达到线程安全的目的，但存在几个明显的问题：首先编码上存在一定的复杂性，相关的代码段都需要添加锁。其次这种一刀切的做法在高并发情况下性能并不理想，基本相当于串行执行。JDK1.5中为我们提供了一系列的并发容器，集中在java.util.concurrent包下，用来解决这两个问题，先从同步容器说起。

同步容器Vector和HashTable

为了简化代码开发的过程，早期的JDK在java.util包中提供了Vector和HashTable两个同步容器，这两个容器的实现和早期的ArrayList和HashMap代码实现基本一样，不同在于Vector和HashTable在每个方法上都添加了synchronized关键字来保证同一个实例同时只有一个线程能访问，部分源码如下：

//Vector
public synchronized int size() {};
public synchronized E get(int index) {};
//HashTable
public synchronized V put(K key, V value) {};
public synchronized V remove(Object key) {};
通过对每个方法添加synchronized，保证了多次操作的串行。这种方式虽然使用起来方便了，但并没有解决高并发下的性能问题，与手动锁住ArrayList和HashMap并没有什么区别，不论读还是写都会锁住整个容器。其次这种方式存在另一个问题：当多个线程进行复合操作时，是线程不安全的。可以通过下面的代码来说明这个问题：

public static void deleteVector(){
int index = vectors.size() - 1;
vectors.remove(index);
}
代码中对Vector进行了两步操作，首先获取size，然后移除最后一个元素，多线程情况下如果两个线程交叉执行，A线程调用size后，B线程移除最后一个元素，这时A线程继续remove将会抛出索引超出的错误。

那么怎么解决这个问题呢？最直接的修改方案就是对代码块加锁来防止多线程同时执行：

public static void deleteVector(){
synchronized (vectors) {
int index = vectors.size() - 1;
vectors.remove(index);
}
}
如果上面的问题通过加锁来解决没有太直观的影响，那么来看看对vectors进行迭代的情况：

public static void foreachVector(){
synchronized (vectors) {
for (int i = 0; i < vectors.size(); i++) {
System.out.println(vectors.get(i).toString());
}
}
}
为了避免多线程情况下在迭代的过程中其他线程对vectors进行了修改，就不得不对整个迭代过程加锁，想象这么一个场景，如果迭代操作非常频繁，或者vectors元素很大，那么所有的修改和读取操作将不得不在锁外等待，这将会对多线程性能造成极大的影响。那么有没有什么方式能够很好的对容器的迭代操作和修改操作进行分离，在修改时不影响容器的迭代操作呢？这就需要java.util.concurrent包中的各种并发容器了出场了。

并发容器CopyOnWrite

CopyOnWrite--写时复制容器是一种常用的并发容器，它通过多线程下读写分离来达到提高并发性能的目的，和前面我们讲解StampedLock时所用的解决方案类似：任何时候都可以进行读操作，写操作则需要加锁。不同的是，在CopyOnWrite中，对容器的修改操作加锁后，通过copy一个新的容器来进行修改，修改完毕后将容器替换为新的容器即可。

这种方式的好处显而易见：通过copy一个新的容器来进行修改，这样读操作就不需要加锁，可以并发读，因为在读的过程中是采用的旧的容器，即使新容器做了修改对旧容器也没有影响，同时也很好的解决了迭代过程中其他线程修改导致的并发问题。

JDK中提供的并发容器包括CopyOnWriteArrayList和CopyOnWriteArraySet，下面通过CopyOnWriteArrayList的部分源码来理解这种思想：

//添加元素
public boolean add(E e) {
//独占锁
final ReentrantLock lock = this.lock;
lock.lock();
try {
Object[] elements = getArray();
int len = elements.length;
//复制一个新的数组newElements
Object[] newElements = Arrays.copyOf(elements, len + 1);
newElements[len] = e;
//修改后指向新的数组
setArray(newElements);
return true;
} finally {
lock.unlock();
}
}
public E get(int index) {
//未加锁，直接获取
return get(getArray(), index);
}
代码很简单，在add操作中通过一个共享的ReentrantLock来获取锁，这样可以防止多线程下多个线程同时修改容器内容。获取锁后通过Arrays.copyOf复制了一个新的容器，然后对新的容器进行了修改，最后直接通过setArray将原数组引用指向了新的数组，避免了在修改过程中迭代数据出现错误。get操作由于是读操作，未加锁，直接读取就行。CopyOnWriteArraySet类似，这里不做过多讲解。

CopyOnWrite容器虽然在多线程下使用是安全的，相比较Vector也大大提高了读写的性能，但它也有自身的问题。

首先就是性能，在讲解ArrayList的文章中提到过，ArrayList的扩容由于使用了Arrays.copyOf每次都需要申请更大的空间以及复制现有的元素到新的数组，对性能存在一定影响。CopyOnWrite容器也不例外，每次修改操作都会申请新的数组空间，然后进行替换。所以在高并发频繁修改容器的情况下，会不断申请新的空间，同时会造成频繁的GC，这时使用CopyOnWrite容器并不是一个好的选择。

其次还有一个数据一致性问题，由于在修改中copy了新的数组进行替换，同时旧数组如果还在被使用，那么新的数据就不能被及时读取到，这样就造成了数据不一致，如果需要强数据一致性，CopyOnWrite容器也不太适合。

并发容器ConcurrentHashMap