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

最新推荐文章于 2024-07-10 21:05:27 发布
最新推荐文章于 2024-07-10 21:05:27 发布
阅读量361 收藏 1
点赞数
分类专栏： Java 程序员 编程 文章标签： java 链表 redis hashmap 数据结构
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/python8989/article/details/113064363
版权
本文探讨了为什么在Java的ConcurrentHashMap中，get操作不需要加锁。通过分析1.8版本的源码，了解到ConcurrentHashMap的无锁实现主要依赖于volatile关键字保证可见性和有序性，以及利用Node的volatile成员val确保线程安全。此外，文章还解释了volatile修饰数组与保证并发安全的区别。
摘要由CSDN通过智能技术生成

目录

  • ConcurrentHashMap的简介
  • get操作源码
  • volatile登场
  • 是加在数组上的volatile吗?
  • 用volatile修饰的Node
  • 总结

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

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

最低0.47元/天 解锁文章
爱玛士
关注
专栏目录
Java 为什么ConcurrentHashMap的读操作不需要加锁？
单枪匹码
10-05 586
我们知道ConcurrentHashMap（1.8）这个并发集合框架是线程安全的，当你看到源码的get操作时，会发现get操作全程是没有加任何锁的，这也是这篇博客需要讨论的问题——为什么它不需要加锁呢？ 1、ConcurrentHashMap的简介： 我想有基础的同学知道在JDK1.7中是采用Segment+HashEntry+ReentrantLock的方式进行实现的，而1.8中放弃了Segment 臃肿的设计，取而代之的是采用Node+CAS+Synchronized来保证并发安全进行实现的。 JDK
常见 Java 面试题：Java 中 ConcurrentHashMap 的 get 方法是否需要加锁？
最新发布
codenav的博客
08-01 345
保证 put 的时候线程安全之后，get 的时候只需要保证可见性即可，而可见性不需要加锁。
java中ConcurrentHashMap的读操作为什么不需要加锁
08-26
ConcurrentHashMap完全允许多个读操作并发进行，读操作并不需要加锁。所以下面这篇文章主要给大家介绍了关于java中ConcurrentHashMap的读操作为什么不需要加锁的相关资料，需要的朋友可以参考下
ConcurrentHashMap的读操作不需要加锁
fll980205的博客
11-08 1919
public V get(Object key) { Node<K,V>[] tab; Node<K,V> e, p; int n, eh; K ek; int h = spread(key.hashCode()); if ((tab = table) != null && (n = tab.length) &...
经典面试题：为什么 ConcurrentHashMap 的读操作不需要加锁？
m0_71777195的博客
07-05 1130
JDK1.8的实现降低锁的粒度，JDK1.7版本锁的粒度是基于Segment的，包含多个HashEntry，而JDK1.8锁的粒度就是HashEntry（首节点）JDK1.8版本的数据结构变得更加简单，使得操作也更加清晰流畅，因为已经使用synchronized来进行同步，所以不需要分段锁的概念，也就不需要Segment这种数据结构了，由于粒度的降低，实现的复杂度也增加了JDK1.8使用红黑树来优化链表，基于长度很长的链表的遍历是一个很漫长的过程，而红黑树的遍历效率是很快的，代替一定阈值的链表，这样形成一个
面试官：ConcurrentHashMap的读操作不需要加锁？
热衷技术的Java程序员
05-16 1010
我们知道， ConcurrentHashmap(1.8)这个并发集合框架是线程安全的，当你看到源码的get操作时，会发现get操作全程是没有加任何锁的，这也是这篇博文讨论的问题——为什么它不需要加锁呢？ ConcurrentHashMap的简介 我想有基础的同学知道在jdk1.7中是采用Segment + HashEntry + ReentrantLock的方式进行实现的，而1.8中放弃了Segment臃肿的设计，取而代之的是采用Node + CAS + Synchronized来保证并发安全进行实
蚂蚁金服面试官：ConcurrentHashMap线程安全吗？
weixin_51439578的博客
12-27 834
前言 没啥深入实践的理论系同学，在使用并发工具时，总是认为把HashMap改为ConcurrentHashMap，就完美解决并发了呀。或者使用写时复制的CopyOnWriteArrayList，性能更佳呀！技术言论虽然自由，但面对魔鬼面试官时，我们更在乎的是这些真的正确吗？整理了100+个Java项目视频+源码+笔记 线程重用导致用户信息错乱 生产环境中，有时获取到的用户信息是别人的。查看代码后，发现是使用了ThreadLocal缓存获取到的用户信息。 ThreadLocal适用于变量在线程间隔离，而在方法
java调用其他类hashmap为空_面试官邪魅一笑: 你说说 Java8 的 ConcurrentHashMap ？
weixin_42311335的博客
02-26 242
来源：cnblogs.com/yangming1996/p/8031199.html一、历史版本的实现演变二、重要成员属性的介绍三、put 方法实现并发添加四、remove 方法实现并发删除五、其他的一些常用方法的基本介绍HashMap 是我们日常最常见的一种容器，它以键值对的形式完成对数据的存储，但众所周知，它在高并发的情境下是不安全的。尤其是在 jdk 1.8 之前，rehash 的过程中采用...
Java 经典面试题：为什么 ConcurrentHashMap 的读操作不需要加锁？
芋道源码
07-05 1130
点击上方“芋道源码”，选择“设为星标”做积极的人，而不是积极废人！源码精品专栏中文详细注释的开源项目RPC 框架 Dubbo 源码解析网络应用框架 Netty 源码解析...
java ConcurrentHashMap锁分段技术及原理详解
08-25
主要介绍了java ConcurrentHashMap锁分段技术详解,文中通过示例代码介绍的非常详细，对大家的学习或者工作具有一定的参考学习价值,需要的朋友可以参考下
JAVA concurrentHashMap加锁
weixin_39304656的博客
07-10 262
例如，当使用 containsValue 方法时，由于需要全局扫描整个哈希表来查找特定的值，而不能像 containsKey 方法那样通过 key 快速定位到对应的 Segment，所以在实现 containsValue 方法时，为了避免出现“ABA 问题”（即一个值先被修改为 A，然后又被改回原来的值 B，而其他线程可能无法察觉到这个中间过程的变化），会使用一些额外的机制，可能涉及到加锁操作。其读操作不需要加锁的原因是，Node 类的元素 val 和指针 next 是用 volatile 修饰的。
为什么ConcurrentHashMap的读操作不需要加锁？
石杉的架构笔记
09-07 732
公众号后台回复“学习”，获取作者独家秘制精品资料扫描下方海报二维码，试听课程：本文来源：Java 技术驿站我们知道，ConcurrentHashmap(1.8)这个并发集...
Java 深入理解 ConcurrentHashMap (数据结构、实现原理、JDK版本区别，读写相关锁)
深海流浪汉
12-21 378
问题： JDK1.7和JDK1.8的ConcurrentHashMap底层数据结构有何区别？ JDK1.7和JDK1.8的ConcurrentHashMap实现原理有何区别？ HashMap、ConcurrentHashMap主要有何区别？ ConcurrentHashMap初始大小、加载因子分别是多少？ ConcurrentHashMap的put方法的主要流程？ 在JDK1.8中ConcurrentHashMap，为何要用synchronized代替ReentrantLock？ ConcurrentHa
Java并发编程之ConcurrentHashMap
weixin_71690375的博客
05-26 810
在确定了链表的头部以后，就可以对整个链表进行遍历，看第4行，取出key对应的value的值，如果拿出的value的值是null，则可能这个key，value对正在put的过程中，如果出现这种情况，那么就加锁来保证取出的value是完整的，如果不是null，则直接返回value。因为实际上put、remove等操作也会更新count的值，所以当竞争发生的时候，volatile的语义可以保证写操作在读操作之前，也就保证了写操作对后续的读操作都是可见的，这样后面get的后续操作就可以拿到完整的元素内容。
ConcurrentHashMap 详解，并发读写剖析
weixin_44985305的博客
02-11 2533
JDK 1.8 优化部分，并发读写实现解析。读写锁场景解读
牛客杂记——CopyOnWriteArrayList----ReadWriteLock---ConcurrentHashMap
char_m的博客
07-01 600
1.CopyOnWirteArrayList 适用于写少读多的并发场景 2.ReadWriteLock 即为读写锁，要求写与写之间互斥，读与写之间互斥，读与读之间可以并发执行，在读多写少的情况下可以提高效率。 允许多个线程同时读共享变量； 只允许一个线程写共享变量； 如果一个写线程正在执行写操作，此时禁止读线程读共享变量； 3.ConcurrentHashMap是同步的HashMap， 读写都加锁 4.volatile 只保证多线程操作的可见性，不保证原子性 例题：下列关于Java并发的说法中正确的是（）
为什么 ConcurrentHashMap 的读操作不需要加锁？
zty
06-29 152
前言 我们知道，ConcurrentHashmap(1.8)这个并发集合框架是线程安全的，当你看到源码的get操作时，会发现get操作全程是没有加任何锁的，这也是这篇博文讨论的问题——为什么它不需要加锁呢？ ConcurrentHashMap的简介 我想有基础的同学知道在jdk1.7中是采用Segment + HashEntry + ReentrantLock的方式进行实现的，而1.8中放弃了Segment臃肿的设计，取而代之的是采用Node + CAS + Synchronized来保证并发安全进行实现
ConcurrentHashMap为什么读不加锁
03-19
在读取数据时，不需要加锁，因为每个段都可以独立地进行读操作，不会产生冲突。而在写入数据时，只需要锁住对应的段，而不是整个哈希表，这样可以最大程度地减少锁的竞争，提高并发性能。 通过使用分段锁，...
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值