面试官：ConcurrentHashMap的读操作不需要加锁？

最新推荐文章于 2021-08-29 19:19:31 发布

热衷技术的Java程序员

最新推荐文章于 2021-08-29 19:19:31 发布

阅读量1k

点赞数

分类专栏：后端 Java 文章标签： java 链表 hashmap 数据结构 redis

本文链接：https://blog.csdn.net/bjmsb/article/details/106161703

版权

本文探讨了JDK1.8中ConcurrentHashMap的get操作为何不需要加锁。通过分析源码，指出这是因为Node的val字段使用了volatile，确保了读操作的可见性和有序性。同时，文章提到数组的volatile保证了在扩容时的可见性，而非用于get操作的并发安全性。

摘要由CSDN通过智能技术生成

我们知道，ConcurrentHashmap(1.8)这个并发集合框架是线程安全的，当你看到源码的get操作时，会发现get操作全程是没有加任何锁的，这也是这篇博文讨论的问题——为什么它不需要加锁呢？

我想有基础的同学知道在jdk1.7中是采用Segment + HashEntry + ReentrantLock的方式进行实现的，而1.8中放弃了Segment臃肿的设计，取而代之的是采用Node + CAS + Synchronized来保证并发安全进行实现。

JDK1.8的实现降低锁的粒度，JDK1.7版本锁的粒度是基于Segment的，包含多个HashEntry，而JDK1.8锁的粒度就是HashEntry（首节点）
JDK1.8版本的数据结构变得更加简单，使得操作也更加清晰流畅，因为已经使用synchronized来进行同步，所以不需要分段锁的概念，也就不需要Segment这种数据结构了，由于粒度的降低，实现的复杂度也增加了
JDK1.8使用红黑树来优化链表，基于长度很长的链表的遍历是一个很漫长的过程，而红黑树的遍历效率是很快的，代替一定阈值的链表，这样形成一个最佳拍档

//会发现源码中没有一处加了锁
public V get(Object key) {
    Node<K,V>[] tab; Node<K,V> e, p; int n, eh; K ek;
    int h = spread(key.hashCode()

关注

专栏目录