HashMap 是线程不安全的，效率高；HashTable 是线程安全的，效率低。

ConcurrentHashMap 可以做到既是线程安全的，同时也可以有很高的效率，得益于使用了分段锁。

实现原理

JDK 1.7：

• ConcurrentHashMap 是通过数组 + 链表实现，由 Segment 数组和 Segment 元素里对应多个 HashEntry 组成
• value 和链表都是 volatile 修饰，保证可见性
• ConcurrentHashMap 采用了分段锁技术，分段指的就是 Segment 数组，其中 Segment 继承于 ReentrantLock
• 理论上 ConcurrentHashMap 支持 CurrencyLevel (Segment 数组数量)的线程并发，每当一个线程占用锁访问一个 Segment 时，不会影响到其他的 Segment

put 方法的逻辑较复杂：

• 尝试加锁，加锁失败 scanAndLockForPut 方法自旋，超过 MAX_SCAN_RETRIES 次数，改为阻塞锁获取
• 将当前 Segment 中的 table 通过 key 的 hashcode 定位到 HashEntry
• 遍历该 HashEntry，如果不为空则判断传入的 key 和当前遍历的 key 是否相等，相等则覆盖旧的 value
• 不为空则需要新建一个 HashEntry 并加入到 Segment 中，同时会先判断是否需要扩容
• 最后释放所获取当前 Segment 的锁

get 方法较简单：

• 将 key 通过 hash 之后定位到具体的 Segment，再通过一次 hash 定位到具体的元素上
• 由于 HashEntry 中的 value 属性是用 volatile 关键词修饰的，保证了其内存可见性

JDK 1.8：

• 抛弃了原有的 Segment 分段锁，采用了 CAS + synchronized 来保证并发安全性
• HashEntry 改为 Node，作用相同
• val next 都用了 volatile 修饰

put 方法逻辑：

• 根据 key 计算出 hash 值
• 判断是否需要进行初始化
• 根据 key 定位出的 Node，如果为空表示当前位置可以写入数据，利用 CAS 尝试写入，失败则自旋
• 如果当前位置的 hashcode == MOVED == -1，则需要扩容
• 如果都不满足，则利用 synchronized 锁写入数据
• 如果数量大于 TREEIFY_THRESHOLD 则转换为红黑树

get 方法逻辑：

• 根据计算出来的 hash 值寻址，如果在桶上直接返回值
• 如果是红黑树，按照树的方式获取值
• 如果是链表，按链表的方式遍历获取值

JDK 1.7 到 JDK 1.8 中的 ConcurrentHashMap 最大的改动：

• 链表上的 Node 超过 8 个改为红黑树，查询复杂度 O(logn)
• ReentrantLock 显示锁改为 synchronized，说明 JDK 1.8 中 synchronized 锁性能赶上或超过 ReentrantLock

参考：

https://www.cnblogs.com/fsychen/p/9361858.html