本文已参与「新人创作礼」活动，一起开启掘金创作之路。
线程安全的基本数据结构
HashTable: 哈希表的线程安全版，效率低
ConcurrentHashMap：哈希表的线程安全版，效率高，用于替代HashTable
Vector：线程安全版Arraylist
Stack：线程安全版栈
BlockingQueue及其子类：线程安全版队列
HashTable
- 底层数组+链表实现，无论key还是value都不能为null，线程安全，实现线程安全的方式是在修改数据时锁住整个HashTable，效率低，ConcurrentHashMap做了相关优化
- 初始size为11，扩容：newsize = oldsize*2+1
- 计算index的方法：index = (hashcode & 0x7FFFFFFF) % tab.length （16进制的0x7FFFFFFF表示int型的最大值，31位1）
HashMap
- 底层数组+链表实现，可以存储null键和null值，线程不安全
- 初始size为16，扩容：newsize = oldsize*2，size一定为2的n次幂
- 扩容针对整个Map，每次扩容时，原来数组中的元素依次重新计算存放位置，并重新插入
- 插入元素后才判断该不该扩容，有可能无效扩容（插入后如果扩容，如果没有再次插入，就会产生无效扩容）
- 当Map中元素总数超过Entry数组的75%，触发扩容操作，为了减少链表长度，元素分配更均匀
- 计算index方法：index = hash & (tab.length – 1)
HashMap的初始值还要考虑加载因子:
- 哈希冲突：若干Key的哈希值按数组大小取模后，如果落在同一个数组下标上，将组成一条Entry链，对Key的查找需要遍历Entry链上的每个元素执行equals()比较。
- 加载因子：为了降低哈希冲突的概率，默认当HashMap中的键值对达到数组大小的75%时，即会触发扩容。因此，如果预估容量是100，即需要设定100/0.75＝134的数组大小。
- 空间换时间：如果希望加快Key查找的时间，还可以进一步降低加载因子，加大初始大小，以降低哈希冲突的概率。
ConcurrentHashMap
- 底层JDK1.7采用分段的数组+链表实现，线程安全，JDK1.8采用synchronized 和 CAS 来操作实现。
- 通过把整个Map分为N个Segment，可以提供相同的线程安全，但是效率提升N倍，默认提升16倍。(读操作不加锁，由于HashEntry的value变量是 volatile的，也能保证读取到最新的值。)
- Hashtable的synchronized是针对整张Hash表的，即每次锁住整张表让线程独占，ConcurrentHashMap允许多个修改操作并发进行，其关键在于使用了锁分离技术
- 有些方法需要跨段，比如size()和containsValue()，它们可能需要锁定整个表而而不仅仅是某个段，这需要按顺序锁定所有段，操作完毕后，又按顺序释放所有段的锁
- 扩容：段内扩容（段内元素超过该段对应Entry数组长度的75%触发扩容，不会对整个Map进行扩容），插入前检测需不需要扩容，有效避免无效扩容
HashMap与ConcurrentHashMap在Jdk1.7和1.8的区别
HashMap
回答：在jdk1.7之前HashMap是基于数组和链表实现的，而且采用头插法。
而jdk1.8 之后在解决哈希冲突时有了较大的变化，当链表长度大于阈值（默认为 8）（将链表转换成**红黑树前会判断，如果当前数组的长度小于 64，那么会选择先进行数组扩容**，而不是转换为红黑树）时，将链表转化为红黑树，以减少搜索时间。采用尾插法。
HashMap默认的初始化大小为 16。当HashMap中的元素个数之和大于负载因子*当前容量的时候就要进行扩充，容量变为原来的 2 倍。（这里注意不是数组中的个数，而且数组中和链/树中的所有元素个数之和！）
ConcurrentHashMap
回答：在jdk1.7是 分段的数组+链表 ，jdk1.8的时候跟HashMap1.8的时候一样都是基于数组+链表/红黑树。
ConcurrentHashMap是线程安全的。
（1）在jdk1.7的时候是使用Segment数组（segment继承reentranlock），每一把锁只锁容器其中一部分数据，多线程访问容器里不同数据段的数据，就不会存在锁竞争，提高并发访问率。
（2）在jdk1.8的时候摒弃了 Segment的概念，而是直接用数组+链表+红黑树的数据结构来实现，并发控制使用 synchronized 和 CAS 来操作。数组元素为空则使用CAS 插入元素，否则使用Synchronized锁定首节点。
CopyOnWriteArrayList
CopyOnWriteArrayList(写时copy的ArrayList)
在很多应用场景中，读操作可能会远远大于写操作。由于读操作根本不会修改原有的数据，因此如果每次读取都进行加锁操作，其实是一种资源浪费。我们应该允许多个线程同时访问 List 的内部数据，毕竟读操作是线程安全的。
这和 ReentrantReadWriteLock 读写锁的思想非常类似，也就是 读读共享、写写 与 写读互斥。JDK中提供了 CopyOnWriteArrayList 类，相比于在读写锁的思想又更进一步。为了将读取的性能发挥到极致，CopyOnWriteArrayList 读取是完全不用加锁的，并且更厉害的是：写入也不会阻塞读取操作，只有写入和写入之间需要进行同步等待，读操作的性能得到大幅度提升。
CopyOnWriteArrayList 是如何做到的
CopyOnWriteArrayList 类的所有可变操作（add，set等等）都是通过创建底层数组的新副本来实现的。当 List 需要被修改的时候，并不直接修改原有数组对象，而是对原有数据进行一次拷贝，将修改的内容写入副本中。写完之后，再将修改完的副本替换成原来的数据，这样就可以保证写操作不会影响读操作了。
从 CopyOnWriteArrayList 的名字可以看出，CopyOnWriteArrayList 是满足 CopyOnWrite 的 ArrayList，所谓 CopyOnWrite 的意思：就是对一块内存进行修改时，不直接在原有内存块中进行写操作，而是将内存拷贝一份，在新的内存中进行写操作，写完之后，再将原来指向的内存指针指到新的内存，原来的内存就可以被回收。
