线程安全的哈希表ConcurrentHashMap

1. HashTable

不推荐使用，无脑给各种方法加锁

2.ConcurrentHashMap

多线程下推荐使用

锁粒度控制

HashTable直接在方法上加synchronized，相当于对哈希表对象加锁，一个哈希表只有一把锁。多线程环境下，无论线程如何操作哈希表，都会产生锁冲突。

而ConcurrentHashMap每个哈希桶都有自己的锁，哈希表中哈希桶数量很多，大大降低了锁冲突的概率，性能也大大提升。

ConcurrentHashMap只对写加锁，读操作不加锁

也就是说两个线程同时修改，才会有锁冲突；两个线程都读，没有锁冲突；一个线程写，一个线程读，也没有锁冲突。
为什么一个线程读一个线程写没有锁冲突？
难道不会读到修改一半的数据吗？ConcurrentHashMap在设计的时候，考虑到这个问题，所以保证在读的时候一定是读到一整数据（要么是旧版本，要么是新版本，不会是读到一半的数据）。
并且读操作也广泛使用volatile保证读到的数据是及时的。

充分利用CAS特性

像维护元素个数就是通过CAS实现，而不是加锁；以及使用CAS实现轻量级锁/自旋锁等等。

对扩容进行特殊处理

HashTable的扩容：当put元素时，发现负载因子超过阈值就触发扩容，申请一个更大的数组，把原来旧的数据搬运到新的数组上。
上述扩容方式存在很大问题，当元素个数特别多的时候，搬运操作就会开销非常大。put操作不需要扩容时瞬间完成O（1），但是触发扩容时就可能卡很久。
ConcurrentHashMap的扩容的时候，旧的数组和新的数组是同时存在的，每次进行哈希表操作都会把旧数组上的元素搬运一部分到新数组上，直到全部搬运完，再释放旧的空间。在这个过程中如果要查询元素，旧的数组和新的数组一起查；如果要插入元素，直接往新数组上插入；如果是删除元素，直接删除不用搬运。