一、前言
完成了JUC的锁框架的分析后，现在分析JUC集合框架，之前分析过的集合框架，很大程度上都不是线程安全的，其在多线程环境下会出现很多问题，为了保证在多线程环境下仍然能够正确安全的访问集合，出现了JUC下的集合框架，下面逐一进行介绍分析。
二、JUC集合框架图
下面给出JUC中的集合框架，之后我们会对其中的类进行详细的分析。
说明：由上图可以看到，JUC的集合框架也是从Map、List、Set、Queue、Collection等超级接口中继承而来的。所以，大概可以知道JUC下的集合包含了一一些基本操作，并且变得线程安全。
三、具体说明
3.1 Map
1. ConcurrentHashMap
支持获取的完全并发和更新的所期望可调整并发的哈希表。此类遵守与 Hashtable 相同的功能规范，并且包括对应于 Hashtable 的每个方法的方法版本。不过，尽管所有操作都是线程安全的，但获取操作不必锁定，并且不支持以某种防止所有访问的方式锁定整个表。ConcurrentHashMap是通过“锁分段”来实现的，支持高并发访问。
2.ConcurrentSkipListMap
线程安全的有序的哈希表(相当于线程安全的TreeMap);映射可以根据键的自然顺序进行排序，也可以根据创建映射时所提供的 Comparator 进行排序，具体取决于使用的构造方法。
3.2 List
1. CopyOnWriteArrayList
ArrayList 的一个线程安全的变体，其中所有可变操作（add、set 等等）都是通过对底层数组进行一次新的复制来实现的。这一般需要很大的开销，但是当遍历操作的数量大大超过可变操作的数量时，这种方法可能比其他替代方法更 有效。在不能或不想进行同步遍历，但又需要从并发线程中排除冲突时，它也很有用。
3.3 Set
1. ConcurrentSkipListSet
一个基于ConcurrentSkipListMap 的可缩放并发 NavigableSet 实现。set 的元素可以根据它们的自然顺序进行排序，也可以根据创建 set 时所提供的 Comparator 进行排序，具体取决于使用的构造方法。
2.CopyOnWriteArraySet
对其所有操作使用内部CopyOnWriteArrayList的Set。即将所有操作转发至CopyOnWriteArayList来进行操作，能够保证线程安全。
3.4 Queue
1. ConcurrentLinkedQueue
一个基于链接节点的*线程安全队列。此队列按照 FIFO（先进先出）原则对元素进行排序。队列的头部 是队列中时间最长的元素。队列的尾部 是队列中时间最短的元素。新的元素插入到队列的尾部，队列获取操作从队列头部获得元素。当多个线程共享访问一个公共 collection 时，ConcurrentLinkedQueue 是一个恰当的选择。此队列不允许使用 null 元素。
2. ConcurrentLinkedDeque
是双向链表实现的*队列，该队列同时支持FIFO和FILO两种操作方式。
3. LinkedBlockingQueue
一个基于已链接节点的、范围任意的 blocking queue。此队列按 FIFO（先进先出）排序元素。队列的头部 是在队列中时间最长的元素。队列的尾部 是在队列中时间最短的元素。新元素插入到队列的尾部，并且队列获取操作会获得位于队列头部的元素。链接队列的吞吐量通常要高于基于数组的队列，但是在大多数并发应用程序中，其可预知的性能要低。
4. LinkedBlockingDeque
一个基于已链接节点的、任选范围的阻塞双端队列。
5. ArrayBlockingQueue
一个由数组支持的有界阻塞队列。此队列按 FIFO（先进先出）原则对元素进行排序。队列的头部 是在队列中存在时间最长的元素。队列的尾部 是在队列中存在时间最短的元素。新元素插入到队列的尾部，队列获取操作则是从队列头部开始获得元素。
3.5 Collection
由于Collection接口下的类在Queue模块中已经介绍过，故不再累赘。
四、总结
关于JUC的集合框架就介绍到这里，之后会进一步分析每一个类。谢谢各位园友的观看~