1. 为什么ConcurrentHashMap是线程安全的
   JDK1.7中，ConcurrentHashMap使用的锁分段技术，将数据分成一段一段的存储，然后给每一段数据配一把锁，当一个线程占用锁访问其中一个段数据的时候，其他段的数据也能被其他线程访问。

2. 那说说JDK1.7中Segment的原理
   刚刚说的一段一段就是指Segment，它继承了ReentrantLock，具备锁和释放锁的功能。ConcurrentHashMap只有16个Segment，并且不会扩容，最多可以支持16个线程并发写。

3. JDK1.8的ConcurrentHashMap怎么实现线程安全的
   JDK1.8放弃了锁分段的做法，采用CAS和synchronized方式处理并发。以put操作为例，CAS方式确定key的数组下标，synchronized保证链表节点的同步效果。

4. JDK1.8的做法有什么好处呢
   1. 减少内存开销
      假设使用可重入锁，那么每个节点都需要继承AQS，但并不是每个节点都需要同步支持，只有链表的头节点（红黑树的根节点）需要同步，这无疑消耗巨大内存。
   2. 获得JVM的支持
      可重入锁毕竟是API级别的，后续的性能优化空间很小。synchronized则是JVM直接支持的，JVM能够在运行时作出相应的优化措施：锁粗化、锁消除、锁自旋等等。使得synchronized能够随着JDK版本的升级而不改动代码的前提下获得性能上的提升。

5. 为什么不推荐使用HashTable呢
   HashTable容器使用synchronized来保证线程安全，但在线程竞争激烈的情况下HashTable的效率非常低下。因为多个线程访问HashTable的同步方法时，可能会进入阻塞或轮询状态。如线程1使用put进行添加元素，线程2不但不能使用put方法添加元素，并且也不能使用get方法来获取元素，所以竞争越激烈效率越低。

参考(部分摘抄的文字版权属于原作者)：

https://segmentfault.com/a/1190000015907000
https://www.cnblogs.com/zhaojj/p/8942647.html
https://www.cnblogs.com/wfq9330/p/9606472.html

鸡汤：上帝为你关上了一扇门，然后去洗洗睡了。