设为首页收藏本站
开启辅助访问

为什么 ConcurrentHashMap 的读操作不需要加锁?

 您所在的位置：网站首页 › 数组volatile › 为什么 ConcurrentHashMap 的读操作不需要加锁?

为什么 ConcurrentHashMap 的读操作不需要加锁?

2024-05-25 10:13| 来源: 网络整理| 查看: 265

文章目录 为什么 ConcurrentHashMap 的读操作不需要加锁？1、ConcurrentHashMap的简介2、get操作源码3、volatile登场4、是加在数组上的volatile吗?5、用volatile修饰的Node6、总结

为什么 ConcurrentHashMap 的读操作不需要加锁？

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

1、ConcurrentHashMap的简介

我想有基础的同学知道在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使用红黑树来优化链表，基于长度很长的链表的遍历是一个很漫长的过程，而红黑树的遍历效率是很快的，代替一定阈值的链表，这样形成一个最佳拍档

2、get操作源码 首先计算hash值，定位到该table索引位置，如果是首节点符合就返回如果遇到扩容的时候，会调用标志正在扩容节点ForwardingNode的find方法，查找该节点，匹配就返回以上都不符合的话，就往下遍历节点，匹配就返回，否则最后就返回null //会发现源码中没有一处加了锁 public V get(Object key) { Node[] tab; Node e, p; int n, eh; K ek; int h = spread(key.hashCode()); //计算hash if ((tab = table) != null && (n = tab.length) > 0 && (e = tabAt(tab, (n - 1) & h)) != null) {//读取首节点的Node元素 if ((eh = e.hash) == h) { //如果该节点就是首节点就返回 if ((ek = e.key) == key || (ek != null && key.equals(ek))) return e.val; } //hash值为负值表示正在扩容，这个时候查的是ForwardingNode的find方法来定位到nextTable来 //eh=-1，说明该节点是一个ForwardingNode，正在迁移，此时调用ForwardingNode的find方法去nextTable里找。 //eh=-2，说明该节点是一个TreeBin，此时调用TreeBin的find方法遍历红黑树，由于红黑树有可能正在旋转变色，所以find里会有读写锁。 //eh>=0，说明该节点下挂的是一个链表，直接遍历该链表即可。 else if (eh


【本文地址】


今日新闻

推荐新闻

CopyRight 2018-2019 办公设备维修网 版权所有 豫ICP备15022753号-3