Java下的线程安全容器
在编写多线程的Java程序时，难免会使用到各种各样的容器。
Java本身提供了许多线程安全的容器，开发者可以按照需求利用这些容器来进行相应的开发。
但Java提供的线程安全容器种类非常多， 拿 Set 来举例，线程安全的 Set 至少有：
- CopyOnWriteArraySet
- ConcurrentSkipListSet
- Collections.synchronizedSet(Set set)
- Collections.newSetFromMap(new ConcurrentHashMap())
- ......
这些容器之间的区别是什么？作为开发者，又该如何对这些容器进行选择呢？
这确实是一件令博主很头疼的一件事情。查阅了网络上的一些资料之后，总算是有了少许的领悟。下面是一些整理：
总的来说，这些线程安全的容器主要分为两类：
- 同步容器类
- 并发容器类
1. 同步容器类
前面提到的 Collections.synchronizedSet(Set set) 就属于这个分类。它实现线程安全的方法是：
在原始的 *Set *中的每一个方法的外部包裹一个 synchronized 块，且只允许调用者访问这些被 synchronized 关键字同步起来的方法。
这样一来，就意味着，不可能有两个或以上的方法被同时执行 （冲突的调用会被阻塞起来，直到前一个方法执行完成）
同步容器类的特点就是：在任何时刻，只允许一个线程访问该容器的状态。这从它的实现方式来看也是显而易见的。
也因为是这样，这类容器一般不具备并发能力，也就是说，如果多个线程同时使用该容器，它们对容器的操作实际上是串行的。
对于同步类容器，有一点需要额外注意：虽然同步类容器是线程安全的容器，在使用其迭代器（iterator）时，仍需要使用 synchronized 关键字在外部对其进行同步。
考虑下述情况：
List<Student> students=Collections.synchronizedList(new ArrayList<Student>());
for(Student student:students)
doSomething(student);
假设线程A在对 students 进行迭代操作的中途，线程B删除了 students 中的一个元素（这完全是有可能的，因为线程A并没有在整个迭代操作过程中获得对 students 的锁），
就会抛出 ConcurrentModificationExceptions 。
为了避免这种情况，应该使用 synchronized 关键字对迭代操作部分的代码进行加锁：
List<Student> students= Collections.synchronizedList(new ArrayList<Student>());
synchronized (students) {
for(Student student:students)
doSomething(student);
}
除了迭代操作，当有多个线程对容器进行访问、删除元素等常见操作时也可能会引发类似的问题，比如抛出 ArrayIndexOutOfBoundException 。
在进行这类操作时，应该将其变成原子的。
当对并发度的要求很低，而又希望对容器的修改可以马上为其它线程可见时，可以考虑使用这类容器。
2.并发容器
并发容器允许多个线程同时对容器进行访问（往往有一定的限制），相比同步类容器，在多线程环境下，并发容器往往具有更优的运行效率。
Copy-On-Write 写时复制容器：
前面提到的CopyOnWriteArraySet是一种写时复制容器，属于并发容器。他实现并发的原理非常的简单，甚至从它的名字就能够看出来：
CopyOnWriteArraySet内部维护着一个数组，当要对元素进行修改时，它就将该数组复制一份，并在复制出来的副本上进行修改，
修改完成后再将原数组的引用指向新的数组。
如果这个时候同时有其它进程对这个容器进行读操作，它们访问的实际上是修改前的旧版本。因此读操作是不需要对容器上锁的。
这是一种读写分离的思想，从而避免了在读者和写者之间进行同步的必要（当然写者和写者直接还是需要同步的）。
可以从其实现中看出，CopyOnWrite 容器存在连个比较显著的不足：
- 内存占用问题：因为写操作需要复制一份原数据的副本，因此会在内存中同时驻扎两份数据，增加了几乎一倍的开销
- 数据一致性问题：因为读写分离，写时复制容器不能保证数据的实时一致性。也就是说写入的数据不能保证马上就能被读到。
如果数据量比较小、预期的读操作远比写操作多，可以考虑使用 CopyOnWrite 容器
其他并发类容器
前面提到的ConcurrentHashMap和 同步容器 以及 写时复制容器 都不同。同步类容器，比如 HashTable，为了保证线程安全，
选择了对整个map进行加锁（map-wide）。这样一来，只要一个线程获得了锁，别的线程就必须等待持有锁的线程退出，这样就极大地降低了CPU的利用率。
ConcurrentHashMap对此进行了优化，相比HashTable，ConcurrentHashMap使用了更细粒度的锁。
首先了解下ConcurrentHashMap的结构模型（引用自developerWorks®）：
ConcurrentHashMap 类中包含两个静态内部类 HashEntry 和 Segment。
HashEntry 用来封装映射表的键 / 值对，其中键和值都不允许为null；
Segment 用来充当锁的角色，每个 Segment 对象守护整个散列映射表的若干个桶。
每个桶是由若干个 HashEntry 对象链接起来的链表。
一个 ConcurrentHashMap 实例中包含由若干个 Segment 对象组成的数组。
示意图：
对ConcurrentHashMap的读操作一般不用加锁就可以操作完成，除非读出的value值为null（说明发生了重排序），才需要加锁重读。
对ConcurrentHashMap的写操作需要进行加锁，但有别于HashTable等同步容器类，进行ConcurrentHashMap的写操作时只需要对相关的segment加锁即可，
其余未上锁的segment仍然可以被其它线程访问。
写线程对容器的修改（增加、删除、替换等）不会影响其它并发读线程对容器的访问。
当有很大的数据集需要处理，且对并发度要求比较高时，可以考虑使用这类容器
总结
Java下的线程安全容器有很多种，对这些容器进行学习和探讨，能够帮助我们在开发过程中选择到更加符合需求的一种容器。
这些不同类型的容器，对于并发和同步的处理都各有特点，我们可以从中获得启发，将其中有用的思想应用到自己的项目中去。
