关于ConcurrentHashMap的size的思考

最新推荐文章于 2025-06-17 11:15:22 发布
原创 最新推荐文章于 2025-06-17 11:15:22 发布 · 3.4k 阅读 · 2 ·
CC 4.0 BY-SA版权
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。

本文深入探讨了Java并发集合类ConcurrentHashMap在处理并发操作时如何兼顾性能与安全性，特别关注了其在求取size方法时采用的策略。通过代码示例，解释了ConcurrentHashMap如何在频繁的add、remove操作与获取元素总数之间找到平衡点，采用分段锁机制确保线程安全的同时优化性能。 
	最近在学习关于java并发的一些知识，因此开通博客记录整个过程，也算是督促一下自己
	ConcurrentHashMap我们都知道的是通过分段锁来控制整个HashMap的安全性，那么求ConcurrentHashMap在求size的时候是如何兼顾到性能以及安全性的呢?
如果只是逐个地获取Segment，那么有可能在后面获取下一个Segment里面的元素的个数的时候，上面一个Segment里面元素的个数已经很可能改变了，因此最后累加到最后，有可能数据是错误的。如果从一开始就获取所有Segment锁的话，又会导致性能低下，因为i你获取了所有的锁，那么别的线程将无法对该HashMap执行任何操作。因此也是不可取的。
	那么ConcurrentHashMap采用的是什么措施呢？我们来看一段代码：
	
	我们可以看到ConcurrentHashMap同时采用了这两个方法，首先去遍历两遍是否在叠加每个Segment的时候，元素的总数会有增加，如果没有增加的话，意味着我们的获取的元素总数是正确的。如果两次都有变化，那么意味着有很大可能这个HashMap非常频繁地执行add、remove操作，这个时候我们不得不采用获取全部Segment锁来获取当前HashMap的元素的总数
yao123long
关注
HashMap多线程安全问题：ConcurrentHashMap解决方案
Java大师兄的博客
06-07 725
在互联网应用中，多线程处理是常态（比如Web服务器同时处理上百个请求）。HashMap作为Java最常用的键值存储结构，在单线程下高效可靠，但多线程环境中却可能引发数据错乱、死循环等严重问题。本文将聚焦这一痛点，从现象到本质，逐步拆解问题，并引出Java官方提供的“安全替代方案”——ConcurrentHashMap。本文将按照“问题现象→原理分析→解决方案→实战验证”的逻辑展开：首先用生活故事类比HashMap的多线程问题；接着拆解HashMap的底层结构，解释为何多线程会导致崩溃；
Java 领域 ConcurrentHashMap 的并发操作性能瓶颈的分析与应对
AI开发架构师
06-09 1025
在分布式系统、高并发服务中，我们常需要一个“线程安全且高效”的哈希存储结构——ConcurrentHashMap（以下简称CHM）几乎是Java开发者的首选。但随着并发量从“百级”提升到“十万级”，许多开发者发现：CHM的性能不再“线性增长”，甚至出现“瓶颈陡降”。本文将聚焦CHM在等核心操作中的性能瓶颈，结合JDK7到JDK17的演进，给出针对性解决方案。先通过“超市货架”的比喻理解CHM的底层结构；分析JDK7（分段锁）与JDK8+（CAS+synchronized）的差异及各自瓶颈；
聊聊java中的哪些Map：（七）ConcurrentHashMap的size方法的一致性分析
dhaibo1986的专栏
08-28 1848
文章目录1.一致性定义1.1 强一致性（Strict Consistency）1.2 弱一致性2.size方法源码2.1 jdk1.8实现2.1.1 size方法2.1.2 sumCount2.1.3 CounterCell2.1.4 addCount2.1.5 fullAddCount2.1.6 总结2.2 jdk1.7源码实现2.2.1 size方法源码2.3 说明 关于ConcurrentHashMap的size方法，有资料说size不能提供强的一致性，但是也有人说size是强一致性的。那么对于这个问
ConcurrentHashMap的size()、mappingCount()的区别，如何扩容？
qq_17376623的博客
08-29 803
1.ConcurrentHashMap是线程安全的，size()和mappingCount()有什么区别呢？ 经查源码，可看到 经比较分析得出：二者返回值不同，为什么会这样？查看英文注释得知，高并发下，如果同时存在insert、remove时，可能会出现不一致，所以推荐使用mappingCount()。 int的范围是 -2^31——2 ^31-1 long的范围是 -2^63——2 ^63-1 2.它在高并发下是怎么保证扩容的？ 它的扩容方法是transfer() 代码非常酷，令人赞叹！该方法的执
Hashtable、HashMap、ConcurrentHashMap常见问题总结+源码解析（Java 8）
lena blog
06-19 417
文章目录为什么HashMap能够存储null值，而Hashtable不可以？Hashtable如何保证线程安全？快速失败和安全失败机制是什么？为什么util包下的集合遍历时修改报错，而util.concurrent包下的不会？ConcurrentHashMap分段锁 为什么HashMap能够存储null值，而Hashtable不可以？ 通过下面的HashMap的源码，我们可以看到containsKey方法遇到null值会返回false，那么hashMap为何能够存储null值呢？ public b
ConcurrentHashMap 的 size 方法原理分析
weixin_33895695的博客
08-01 1032
2019独角兽企业重金招聘Python工程师标准>>> ...
ConcurrentHashmap中的size()方法简单解释
weixin_33955681的博客
08-21 1803
本文所有的源码都是基于JDK1.8 ConcurrentHashmap中的size()方法源码： public int size() { long n = sumCount(); return ((n < 0L) ? 0 : (n > (long)Integer.MAX_VALUE) ? Integer.MA...
关于jdk1.8中ConcurrentHashMap
一叶一菩提的博客
09-23 1307
1.前言 Java JDK升级到1.8后有些集合类的实现有了变化， 其中ConcurrentHashMap就有进行结构上的大调整。 jdk1.6、1.7实现的我不会想了解去百度吧 2. 重要概念 想要了解ConcurrentHashMap 你至少要对HashMap有一定的了解吧？ HashMap（1.8）和ConcurrentHashMap（1.8） 底层都是hash表+链表+红黑树 如果对红黑树不了解的可以查看https://blog.youkuaiyun.com/A980719/article/details/12
HashMap和ConcurrentHashMap的区别（源码分析+个人总结）
一年，我很需要这一年
06-17 954
HashMap和ConcurrentHashMap(个人心得)
ConcurrentHashMap 并发扩容骚操作
SuperStonne的专栏
01-06 2369
上期问题 少年，老衲看你骨骼清奇，眉宇之间透露着一股王者的气息。来吧，跟我讲讲 ConcurrentHashMap 是如何进行管理它的容量的，也就是当我们调用它的 size 方法的时候发生了什么故事？（前面我们介绍了 ConcurrentHashMap 的实现原理，但是扩容和容量大小留了个小尾巴，今天来割一下这个小尾巴，嘿嘿） 我的答案 毕竟是要支持并发，ConcurrentHashMap 的扩容...
concurrenthashmap的size方法原理
滚蛋吧，生活。
09-15 8310
同上，这也是同一个面试的时候别人问的，我只是记得看过，在concurrenthashmap中会统计多次，当时就说会统计两次进行比较，人家接着问为啥。。。我傻了一下，这不是明摆着两次统计的中间有新的变化了，会导致统计不准确吗？当时也不知道说啥好，以为他有新的点，就说不知道。面试时很多问题其实冷静下来想一下，可以更进一步的，有时候其实也是怕他更进一步后下面的挖坑挖大了。 下面具体说一下这个size方...
ConcurrentHashMap如何实现size方法
u012534547的博客
09-27 622
的size()方法通过遍历所有段的计数器实现键值对的总数，考虑到并发环境的特点，返回值可能不完全准确，但设计上确保了高效性和较低的锁竞争。
ConcurrentHashmap size(1.7 1.8)
lucky_C的博客
03-28 1101
ConcurrentHashmap size 1.8方法实现 1.8中使用一个volatile类型的变量baseCount记录元素的个数，当插入新数据或则删除数据时，会通过addCount()方法更新baseCount，实现如下： if ((as = counterCells) != null || !U.compareAndSwapLong(this, BASECOUNT, b = b...
并发编程 —— ConcurrentHashMap size 方法原理分析
weixin_34242509的博客
04-30 532
前言 ConcurrentHashMap 博大精深，从他的 50 多个内部类就能看出来，似乎 JDK 的并发精髓都在里面了。但他依然拥有体验良好的 API 给我们使用，程序员根本感觉不到他内部的复杂。但，他内部的每一个方法都复杂无比，就连 size 方法，都挺复杂的。 今天就一起来看看这个 size 方法。 size 方法 代码如下： public int size() { long n ...
【JUC并发编程】11 ConcurrentHashMap如何计算Size
健身变秃，coding变强
11-16 4895
一、前言 我们都知道，ConcurrentHashmap这个并发集合框架是线程安全的， 二、ConCurrentHashMap#size()方法
ConcurrentHashMap的size的思考
yaotai8135的博客
08-29 1712
ConcurrentHashMap是通过分段锁来控制整个Map的安全性和并发性，那么ConcurrentHashMap在求size的时候是如何兼顾到性能以及安全性的呢? 我们首先会想到以下两种方法： 1. 获取所有的Segment锁。这个方法是可行的，但是这会导致并发性能变差，因为你获取了所有的锁，那么别的线程将无法对该HashMap执行任何操作。 2. 逐个地获取Segment。这...
ConcurrentHashMap 源码之size方法
meser88的博客
03-19 711
JDK1.7实现前提：每个Segment都有一个modCount变量，每当进行一次put、remove和clean等操作(简称写操作)，modCount将会 +1。只要modCount发生了变化就认为容器的大小也在发生变化。 public int size() { // Try a few times to get accurate count...
ConcurrentHashMap
txwy12的博客
04-16 393
1、ConcurrentHashMap的哪些操作需要加锁？ 答：只有写入操作才需要加锁，读取操作不需要加锁 2、ConcurrentHashMap的无锁读是如何实现的？ 答：首先HashEntry中的value和next都是有volatile修饰的，其次在写入操作的时候通过调用UNSAFE库延迟同步了主存，保证了数据的一致性 3、在多线程的场景下调用size（）方法获取ConcurrentHashMap的大小有什么挑战？ConcurrentHashMap是怎么解决的？ 答：size()具有全局的语义，如何能
ConcurrentHashMap解读
weixin_44861399的博客
06-16 659
文章目录前言JDK1.7大致了解源码分析归纳总结JDK1.8大致了解源码分析归纳总结 前言 HashMap： 在多线程情况下，put操作的时候，插入的元素超过了容量（由负载因子决定）的范围就会触发扩容操作，这个会重新将原数组移动到到新的扩容数组中，在多线程的环境下，存在同时其他的元素也在进行put操作，如果hash值相同，可能出现同时在同一数组下用链表表示，造成闭环，导致在get时会出现死循环，这也造成了HashMap线程不安全。 JDK1.7 大致了解 源码分析 归纳总结 JDK1.8 大致了解 源码
为什么说 concurrenthashmap 在多线程下高效 hashmap 在单线程下高效
最新发布
10-15
<think>嗯，用户询问的是ConcurrentHashMap在多线程下高效而HashMap在单线程下高效的原因。这是一个关于Java集合类性能差异的核心问题，我需要深入解析底层机制。 从引用的资料来看，有几个关键点值得注意：引用1明确指出单线程场景HashMap性能优于ConcurrentHashMap；引用3提到ConcurrentHashMap采用分段锁+CAS的设计理念；引用5则通过代码示例展示了ConcurrentHashMap在遍历时删除的安全性。这些正好构成回答的骨架。 先思考HashMap的优势点。在单线程环境下，它的高效主要源于两点：首先是完全无锁的数据结构，所有操作直接访问数组和链表/红黑树，没有同步开销；其次是优化过的哈希算法和扰动函数，碰撞概率低。这就像单人开车不需要考虑车道协调，可以全速行驶。 再分析ConcurrentHashMap的并发优势。引用3提到的分段锁设计很形象——类似高速公路的多车道并行。具体来说，在JDK7是通过Segment划分区块，不同线程操作不同区块时互不影响；到了JDK8则升级为更细粒度的桶级别锁+CAS+volatile组合。特别值得注意的是它在迭代器设计上的巧思：引用5的示例显示即使遍历时修改数据也不会抛出ConcurrentModificationException，这得益于它采用弱一致性的迭代器而非HashMap的快速失败机制。 不过用户可能没意识到的是，ConcurrentHashMap的性能优势仅在写竞争激烈时才明显。如果是纯读场景，由于它完全无锁的读实现（通过volatile保证可见性），性能几乎和HashMap持平。这点值得在回答中强调。 还需要解释为什么ConcurrentHashMap在单线程时稍慢：每次操作要处理线程哈希、访问volatile变量、可能的CAS重试等。虽然JDK不断优化，但基础开销仍存在。就像检查站再高效也会让单车道的车流变慢。 最后要提醒实践要点：引用4给出的替换方案看似简单，但特别强调要验证所有依赖代码。这引出一个深层问题——线程安全是系统性工程，单纯替换集合类可能不够，需要整体考虑原子性操作等问题。 </think>ConcurrentHashMap在多线程下高效而HashMap在单线程下高效的原因主要源于**设计目标差异**和**同步机制开销**，具体分析如下： --- ### **一、HashMap在单线程下高效的原因** 1. **零同步开销** HashMap无任何同步控制（如`synchronized`或`CAS`），所有操作直接访问底层数组。单线程场景下避免了锁竞争、上下文切换等额外开销。 2. **优化的哈希算法** 通过扰动函数（如JDK8的`hash = key.hashCode() ^ (key.hashCode() >>> 16)`）降低哈希碰撞概率，链表/红黑树转换保证$O(1)$~$O(\log n)$的操作效率。 3. **内存访问局部性** 数据连续存储于数组，CPU缓存命中率高，适合单线程快速遍历（如`for`循环）。 > 💎 **本质**：牺牲线程安全性换取极致速度。 --- ### **二、ConcurrentHashMap在多线程下高效的原因** #### 🔧 **并发控制机制演进** | **版本** | **核心机制** | **优化点** | |----------|------------------------|-----------------------------------------| | JDK7 | **分段锁（Segment）** | 将数组分为16段，不同段可并发操作[^3] | | JDK8+ | **CAS + synchronized** | 桶粒度锁（锁单个链表/树节点），降低冲突 | #### 🚀 **高效关键设计** 1. **分段锁（JDK7）** 类比高速公路多车道：线程操作不同段（Segment）互不阻塞，并发度由段数决定（默认16）。 2. **CAS + 桶锁（JDK8）** - **读操作**：无锁访问（`volatile`变量保证可见性） - **写操作**： - 空桶插入 → CAS原子操作 - 非空桶 → 对桶头节点加`synchronized` ```java // JDK8 putVal() 核心逻辑（简化） if ((f = tabAt(tab, i = (n - 1) & hash)) == null) { if (casTabAt(tab, i, null, new Node<K,V>(hash, key, value))) // CAS插入 break; } else { synchronized (f) { // 锁住桶头节点 // 链表/红黑树操作 } } ``` 3. **弱一致性迭代器** 迭代时允许并发修改，通过遍历原数组快照避免`ConcurrentModificationException`[^5]，适合高并发遍历场景。 4. **扩容优化** 多线程协同扩容（线程迁移不同桶段），避免单点瓶颈。 > 💎 **本质**：最小化锁粒度 + 无锁读 + 并发扩容 → 高吞吐量。 --- ### **三、性能对比总结** | **场景** | HashMap | ConcurrentHashMap | |----------------|---------------------|----------------------------| | **单线程操作** | ⚡ 无锁，速度极快 | ⚠️ 有并发控制开销，略慢 | | **多线程操作** | ❌ 数据损坏风险 | ✅ 安全高效 | | **迭代修改** | ❌ 快速失败异常 | ✅ 弱一致性，安全遍历[^5] | --- ### 📚 **核心结论** 1. **单线程选HashMap** 无同步开销，性能碾压任何线程安全容器（包括ConcurrentHashMap）[^1]。 2. **多线程选ConcurrentHashMap** 分段锁/CAS+桶锁实现**并发度与容器大小解耦**，冲突越少性能越接近HashMap[^3][^4]。 3. **避免HashTable** 全表锁（`synchronized`方法级）导致并发度=1，性能最差。 > ⚠️ **误区警示**： > 即使使用ConcurrentHashMap，**复合操作**（如`map.putIfAbsent()`）仍需外部同步保证原子性！ --- ### 相关问题 1. ConcurrentHashMap在JDK7和JDK8中的实现有哪些本质区别？ 2. 为什么ConcurrentHashMap的迭代器不会抛出ConcurrentModificationException？ 3. 如何在保证线程安全的前提下进一步提升ConcurrentHashMap的写性能？ 4. HashMap在多线程下可能引发哪些具体问题（如死循环）？ 5. ConcurrentHashMap的`size()`方法为何需要特殊设计？
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
表情包 代码片
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值