为什么HashTable慢
Hashtable之所以效率低下主要是因为其实现使用了synchronized关键字对put等操作进行加锁，而synchronized关键字加锁是对整个对象进行加锁，也就是说在进行put等修改Hash表的操作时，锁住了整个Hash表，从而使得其表现的效率低下。
ConcurrentHashMap - JDK 1.7
在JDK1.5~1.7版本，Java使用了分段锁机制实现ConcurrentHashMap.简而言之，ConcurrentHashMap在对象中保存了一个Segment数组，即将整个Hash表划分为多个分段；而每个Segment元素，即每个分段则类似于一个Hashtable；这样，在执行put操作时首先根据hash算法定位到元素属于哪个Segment，然后对该Segment加锁即可。因此，ConcurrentHashMap在多线程并发编程中可是实现多线程put操作。
JDK1.7版本中ConcurrentHashMap的实现原理。
数据结构
ConcurrentHashMap 是一个 Segment 数组，Segment 通过继承 ReentrantLock 来进行加锁，所以每次需要加锁的操作锁住的是一个 segment，这样只要保证每个 Segment 是线程安全的，也就实现了全局的线程安全。concurrencyLevel: 并行级别默认是 16。initialCapacity:初始容量，指整个 ConcurrentHashMap 的初始容量。loadFactor 负载因子，Segment 数组不可以扩容，所以这个负载因子是给每个 Segment 内部HashEntry使用的.
put 新元素时 HashEntry 不存在：
1、如果当前容量大于扩容阀值，小于最大容量，进行扩容。
2、直接头插法插入。
put 新元素时 HashEntry 存在：
1、判断链表当前元素 Key 和 hash 值是否和要 put 的 key 和 hash 值一致。一致则替换值
2、不一致，获取链表下一个节点，直到发现相同进行值替换，或者链表表里完毕没有相同的。
3、如果当前容量大于扩容阀值，小于最大容量，进行扩容。
4、直接链表头插法插入。
并发问题分析
1、put 加锁
2、get 使用了volatile
3、remove 先执行get操作
ConcurrentHashMap - JDK 1.8
在JDK1.8中，ConcurrentHashMap结构是 Node 数组 + 链表 / 红黑树。当冲突链表达到一定长度时，链表会转换成红黑树。ConcurrentHashMap的Put操作采用CAS和synchronized实现。
ConcurrentHashMap 的初始化是通过自旋和 CAS 操作完成的。里面需要注意的是变量 sizeCtl ，它的值决定着当前的初始化状态。
1、-1 说明正在初始化
2、-N 说明有N-1个线程正在进行扩容
3、表示 table 初始化大小，如果 table 没有初始化
4、表示 table 容量，如果 table 已经初始化。
总结
Java7 中 ConcurrentHashMap 使用的分段锁，也就是每一个 Segment 上同时只有一个线程可以操作，每一个 Segment 都是一个类似 HashMap 数组的结构，它可以扩容，它的冲突会转化为链表。但是 Segment 的个数一但初始化就不能改变。
Java8 中的 ConcurrentHashMap 使用的 Synchronized 锁加 CAS 的机制。结构也由 Java7 中的 Segment 数组 + HashEntry 数组 + 链表 进化成了 Node 数组 + 链表 / 红黑树，Node 是类似于一个 HashEntry 的结构。它的冲突再达到一定大小时会转化成红黑树，在冲突小于一定数量时又退回链表。
