本文探讨了ConcurrentHashMap在JDK1.8中的实现如何保证线程安全，不再依赖Segment而是通过细粒度的锁来实现。在数据结构上，1.8版使用了红黑树优化长链表的遍历。get操作中，通过计算hash值定位节点，并结合volatile确保可见性和有序性。当发生扩容时，会涉及ForwardingNode的find方法。volatile关键字在这里起到了关键作用，确保了修改的即时可见性并避免指令重排序。
谈谈ConcurrentHashMap是如何保证线程安全的
我们知道，ConcurrentHashmap(1.8)这个并发集合框架是线程安全的，当你看到源码的get操作时，会发现get操作全程是没有加任何锁的，这也是这篇博文讨论的问题——为什么它不需要加锁呢？
ConcurrentHashMap的简介
JDK1.8的实现降低锁的粒度，JDK1.7版本锁的粒度是基于Segment的，包含多个HashEntry，而JDK1.8锁的粒度就是HashEntry（首节点）JDK1.8版本的数据结构变得更加简单，使得操作也更加清晰流畅，因为已经使用synchronized来进行同步，所以不需要分段锁的概念，也就不需要Segment这种数据结构了，由于粒度的降低，实现的复杂度也增加了JDK1.8使用红黑树来优化链表，基于长度很长的链表的遍历是一个很漫长的过程，而红黑树的遍历效率是很快的，代替一定阈值的链表，这样形成一个最佳拍档。
get操作源码
-
首先计算hash值，定位到该table索引位置，如果是首节点符合就返回
-
如果遇到扩容的时候，会调用标志正在扩容节点ForwardingNode的find方法，查找该节点，匹配就返回
-
以上都不符合的话，就往下遍历节点，匹配就返回，否则最后就返回null
[Java] 纯文本查看 复制代码
|
01
02
03
04
05
06
07
08
09
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
|
最低0.47元/天 解锁文章
712
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
