我先说个结论如果你还在用synchronized包HashMap或者自己手写锁来管理缓存那多半还没真正吃透ConcurrentHashMap。这个从JDK 5就存在的并发容器到现在依然是Java并发编程里“既要线程安全、又要高性能”的标准答案Java面试问它线上排查问它连中间件源码里也到处是它的身影。这篇文章我不打算给你背教科书而是以实战视角彻底拆解ConcurrentHashMapJDK 7和JDK 8两代实现的核心差异、put/get/扩容这些高频方法的底层逻辑、日常开发里最容易踩的五个坑以及单机和分布式场景下的选型建议。内容会比较干但绝对能让你在看完之后既能应付面试连环问也能在代码评审和线上问题排查里更有底气。1. 设计思路拆解为什么HashMap不香了又为什么不用全局锁1.1 HashMap的非线程安全到底不安全在哪要理解ConcurrentHashMap存在的意义得先搞清楚HashMap在多线程环境下是怎么“挂”的。JDK 7时代HashMap最著名的死循环问题就是多线程并发put触发扩容多个线程同时操作链表头插法导致链表成环下一次get时CPU直接飙满。JDK 8虽然把头插改成了尾插死循环问题从结构上被消除但数据覆盖、size计数错乱、甚至get到null这些线程安全问题依然存在。比如两个线程同时put不同key恰好落在同一个桶上一个线程写入后另一个线程覆盖了前一个的value最终丢失更新这种问题在缓存场景下尤其隐蔽表面看不出异常但数据就是悄悄错了。所以多线程场景下直接用HashMap基本等于埋雷。但你如果给HashMap外面套一层synchronized或者用Hashtable又会遇到另一个问题所有读写操作都串行化并发越高、性能越差。一个简单的缓存读写QPS稍微上来一点锁竞争就能把CPU空转耗尽。ConcurrentHashMap的思路就很直白不追求绝对无锁而是把锁的粒度做到足够细让大多数操作根本碰不到锁竞争。1.2 JDK 7的分段锁设计JDK 7的ConcurrentHashMap采用分段锁Segment机制。它内部维护一个Segment数组每个Segment继承自ReentrantLock默认16个Segment每个Segment里面又是一个小的HashEntry数组。put一个key时先通过hash定位到某个Segment然后只需要锁住这个Segment其他Segment的读写完全不受影响。这样理论上并发度就是Segment的数量默认16。这种设计在当时已经是很大的进步但有两个明显问题第一Segment数量在构造时定死无法扩容并发量上去了就卡在16路并发第二get操作虽然不加锁但依然要经过两次hash定位先定位Segment再定位桶而且在读的过程中如果正好遇到扩容读到的可能是旧链表的节点一致性偏弱。1.3 JDK 8的CAS synchronized演进JDK 8彻底重写了ConcurrentHashMap放弃Segment改成Node数组 CAS synchronized的组合。这是整个演进里我最欣赏的一次设计直接用CAS处理桶为空的插入只有在桶内已有节点、发生hash冲突时才加synchronized锁住链表头节点或红黑树根节点。这个改动带来三个质变第一锁粒度从Segment级细化为单个桶级并发度从固定16提升到理论上的数组长度级别默认数组长度16实际能抗的并发远远超过JDK 7第二读操作几乎无锁化Node的value和next都用volatile修饰读的时候靠volatile的可见性保证拿到最新值第三扩容支持多线程协助迁移彻底告别了JDK 7扩容时其他线程只能干等的局面。一句话总结JDK 8的ConcurrentHashMap在“并发安全”和“并发性能”之间找到了更好的平衡点这也是它至今仍是并发容器首选的根本原因。2. 核心机制精讲put、get、扩容和计数的底层逻辑2.1 put方法从CAS到synchronized的降级路径put是理解ConcurrentHashMap的钥匙。它的完整流程可以拆成四步第一步计算hash。key的hashCode经过一次扰动函数(h ^ (h 16))把高位信息扩散到低位目的是让hash在数组长度较小时也能尽可能散列均匀减少碰撞。第二步检查数组是否为空。如果table还没初始化就调用initTable()进行懒加载初始化。这里有个细节sizeCtl这个volatile变量承担了初始化锁的职责多个线程同时进入initTable时通过CAS把sizeCtl从0改成-1谁成功谁初始化失败的线程调用Thread.yield()让出CPU直到初始化完成。第三步定位桶。如果定位到的桶下标位置是null直接CAS写入新节点这一步无锁完成也是并发性能最大的来源。第四步如果桶位置已经有节点进入synchronized代码块。这里要判断桶里的节点是普通链表节点、还是树节点TreeBin链表就尾插树就走红黑树的插入逻辑。插入完成后如果链表长度超过TREEIFY_THRESHOLD 8尝试调用treeifyBin转红黑树但转树之前还有个判断如果数组长度小于MIN_TREEIFY_CAPACITY 64优先扩容而不是转树。还有一个容易忽视的细节key和value都禁止为null。这是和HashMap最大的行为差异之一原因很简单——并发容器无法通过返回值区分“key不存在”和“value为null”如果允许nullget返回null时你根本不知道是没找到还是值就是null所以设计上直接禁止从源头消除歧义。2.2 get方法无锁读的关键在于volatileget的流程看起来比put简单得多计算hash定位桶如果是null直接返回null然后遍历链表或红黑树找到匹配节点。但它“无锁却安全”的关键全在Node节点的设计上。Node的val和next字段都是volatile修饰的volatile保证了一个线程的写入对另一个线程立即可见。put线程在synchronized块内修改了节点的valget线程不需要加锁读取时也能看到最新值。不过这里有一个很重要的语义要澄清get看到的“最新”是基于volatile语义的最新而不是基于锁的串行化保证。如果put操作还没执行到“写入val”这一步get读到的就是旧值或null这是正常的线性化行为不是bug。对于大多数缓存读多写少的场景这个强度完全够用。另外一个关于扩容的细节get遇到ForwardingNode扩容标记节点hash值为-1时会跳到扩容后的新数组去继续找。JDK 8的扩容是边迁移边读所以get不会阻塞只是可能在新旧数组之间跳转一次。2.3 扩容机制多线程协助迁移的妙处扩容是ConcurrentHashMap整个设计里最复杂的部分也是很多人源码看不下去的地方。我挑重点讲。触发扩容的条件有两个一是链表长度超过8且数组长度小于64二是元素总数超过sizeCtl阈值sizeCtl 数组长度 * 0.75负载因子。扩容时transfer方法被调用它先把数组长度翻倍保持2的幂次然后从旧数组的最后一个桶开始从后往前迁移。关键来了迁移过程中每迁移完一个桶就在旧数组的该桶位置放入一个ForwardingNodehash值为-1。其他线程执行put或get时如果发现桶是ForwardingNode就会主动加入迁移工作通过CAS竞争分配自己的迁移区间这就是“多线程协助扩容”。扩容期间新插入的数据怎么办put线程看到ForwardingNode后会调用helpTransfer加入迁移或者等迁移完这个桶再写入新数组。迁移完成的桶旧数组位置永远被ForwardingNode占着不会再被写入所以不会出现新旧数组数据不一致的覆盖问题。每次扩容的步长stride默认是N / (CPU核数 * 8)每个线程至少负责16个桶的迁移。这种设计让扩容不再是“一条线程的独角戏”在多核机器上扩容效率提升非常明显。2.4 计数逻辑用LongAdder思路解决并发统计问题ConcurrentHashMap统计元素个数用的不是简单的atomic计数器而是借鉴了LongAdder的思路维护一个baseCount同时维护一个CounterCell[]数组。put成功后先尝试CAS累加baseCount如果竞争失败就随机选一个CounterCell累加。sumCount时把所有CounterCell的值和baseCount加起来。这样做的好处是写多线程竞争计数时大家分散到不同的Cell上降低单点CAS冲突性能比Single AtomicInteger高得多。这个设计在LongAdder类里也能看到本质上是用空间换并发。如果你用map.size()做精确判断比如“缓存超过10000就清理”size()返回的是一个近似值因为求和过程中仍有并发写入。绝大多数场景够用但如果要强一致性的精确值得额外加锁或用其他方案。3. 实操指南并发场景下的使用姿势与性能对比3.1 高频场景的推荐写法ConcurrentHashMap最常用的几个场景我列一下每个都附上推荐写法场景一本地缓存读多写少。直接get判空后put性能足够好但要注意多线程同时put同一个key时value的构造过程会有重复。更优的写法是配合computeIfAbsent让value的构造逻辑也在并发控制下执行。场景二统计计数。比如统计每个用户的请求次数map的key是用户IDvalue是计数器。这种场景推荐用LongAdder作为value而不是AtomicInteger配合compute方法做累加能扛更高的并发。场景三KV存储、需要原子性的复合操作。比如“如果key不存在就写入”“如果value满足条件就替换”用putIfAbsent、replace(k, oldV, newV)这些自带原子语义的方法不要自己get再判断再put那一步拆开就不安全了。场景四异步任务的去重。比如多线程捞取任务时用putIfAbsent把正在处理的任务ID放进去返回值不为null说明别人已经处理了天然防重复。3.2 与HashMap、Hashtable、Collections.synchronizedMap的性能对比我用一个简单的JMH基准测试对比过四种Map在8线程并发写场景下的吞吐结果很有代表性ConcurrentHashMap遥遥领先Collections.synchronizedMap最慢Hashtable和它差不多裸HashMap能跑但数据是错的没有比较意义。容器并发写吞吐锁粒度线程安全适用建议HashMap高但错误无锁不安全单线程或读多写少且可容忍数据丢失Hashtable低全表锁安全遗留代码新代码不建议synchronizedMap最低全表锁安全简单场景低并发可用ConcurrentHashMap最高桶级锁CAS安全绝大多数多线程KV场景首选差距的根本原因就是锁粒度。全表锁意味着任何读写都要排队并发越高排队越严重桶级锁让不同key的读写完全并行只有hash冲突的key才需要竞争同一把锁。3.3 初始化参数容量和并发度怎么设ConcurrentHashMap构造时可以传initialCapacity它内部会计算出一个比传入值大的、最小的2的幂次作为初始数组长度。比如你传20实际初始容量是32传100实际是128。这里有个实践经验如果你能预估出大概的容量一定要设置initialCapacity避免频繁扩容。比如你要缓存10万条配置初始容量直接设10万内部实际是131072扩容次数能省则省。JDK 7时代还有个concurrencyLevel参数用来控制Segment数量JDK 8里它已经退化为一个提示参数不能真的控制并发度。如果你还在网上看到“设置concurrencyLevel提升并发”的帖子那基本是在讲JDK 7的旧设计别照搬到JDK 8。4. 常见问题与排坑实录4.1 坑一size()不是精确值很多人在缓存清理场景里用if (map.size() MAX) doClean()这在并发下是不准的。size()只是sumCount的近似快照两个线程同时执行size()可能会得到略有差异的结果甚至size()执行过程中新put进来的元素没被统计进去。解法要根据场景来如果是TOMCAT这类容器的Session管理允许近似值就直接用如果必须精确可以额外维护一个AtomicInteger自行计数或者干脆换成支持强一致性的数据结构比如用锁保护的TreeMap。4.2 坑二computeIfAbsent的递归死锁陷阱JDK 8新增的computeIfAbsent用起来很爽但有一个官方文档明确点名的坑在computeIfAbsent的映射函数里不能再对同一个map做查询、更新操作会导致死锁或IllegalStateException: Recursive update。我见过一个真实案例有人用ConcurrentHashMap做两级缓存A缓存的value为空时在computeIfAbsent的回调里去查B缓存而B缓存恰好也在用computeIfAbsent回的调里去查A两个线程互相等待直接卡死应用。正确姿势是computeIfAbsent的回调函数里只做“创建value”的事情绝不能再碰同一个map。4.3 坑三迭代器是弱一致性的不允许一边遍历一边修改ConcurrentHashMap的迭代器是弱一致性的它不保证一定能看到迭代过程中新插入的元素也不会抛出ConcurrentModificationException。这个特性在大多数场景是好事但如果你在迭代时直接调用remove或put行为可能和预期不一致。迭代器里有remove方法但它是基于迭代器当前位置的如果你用map.remove(key)这种方式在遍历过程中删除不报错但删除的元素可能仍然被遍历到也可能遍历不到结果不确定。如果你需要“遍历并删除满足条件的元素”推荐先把要删的key收集到一个list里遍历结束后统一调用map.removeAll(keys)。4.4 坑四value不能为null前面提过ConcurrentHashMap的key和value都禁止为null。如果你往里面存null会直接抛NullPointerException。很多从HashMap迁移过来的老代码没注意这个差异。解决方案如果确实需要“null值”的语义用Optional包装一层或者在上层统一约定一个空对象常量替代null。4.5 坑五错误的“先检查后操作”模式看看这段代码if (!map.containsKey(key)) { map.put(key, value); }在并发下这是错误的。两个线程可能同时通过containsKey的检查然后同时执行put后写的覆盖先写的。正确做法是直接用putIfAbsentmap.putIfAbsent(key, value);这个方法的原子性由内部实现保证比“检查后再放”可靠得多。同理“先get再根据结果决定是否删除”也应该改成remove(key, value)的条件删除版本。5. 进阶从源码到面试的真实考题5.1 面试官爱问的为什么链表转红黑树的阈值是8这个问题几乎每次面试都会出现。8这个数字不是拍脑袋定的它来自泊松分布的概率计算。在负载因子0.75、hash随机性良好的前提下同一个桶里出现8个节点的概率大约是千万分之六这个概率已经足够低。或者说链表长度达到8时说明hash分布已经出现严重不均匀此时用红黑树替换链表把O(n)的查询降到O(log n)是合理的性能兜底。同时红黑树节点TreeNode的内存占用是普通链表节点的两倍所以不能一来就转树必须超过8且数组长度达到64才转避免小数组时频繁树化反而浪费内存。5.2 面试官爱问的扩容时其他线程的读写会阻塞吗不会阻塞。读操作会通过ForwardingNode跳到新数组去找数据写操作会参与迁移或者等当前桶迁移完成后再写入新数组。只有正在迁移的那个桶会短暂地处于“半迁移”状态此时对该桶的写操作需要等待一下但这是毫秒级的且一个桶的迁移非常快。JDK 7的扩容则完全不同扩容期间所有读写都会被阻塞因为Segment级的锁把整个分段都锁住了。这也是JDK 8重点优化的原因。5.3 面试官爱问的ConcurrentHashMap能替代Redis做分布式缓存吗这个问题我面试别人时经常问。答案是不能。ConcurrentHashMap的线程安全只限于单个JVM进程内。你部署两台应用服务器每台都有自己的map用户第一次请求打到机器A写入缓存第二次请求负载均衡到机器B数据就miss了。所以跨进程、跨节点的共享缓存依然需要Redis、Caffeine本地缓存 分布式缓存组合等方案。ConcurrentHashMap在单机本地缓存层面是最优解之一但它解决不了分布式一致性问题。5.4 一个综合实战基于ConcurrentHashMap实现本地限流器最后分享一个我自己项目里用过的思路就是用ConcurrentHashMapLongAdder实现一个简单的滑动窗口限流器。核心逻辑是以时间窗口为key窗口内的请求计数为value每来一个请求就在当前窗口的LongAdder上累加超过阈值就拒绝。public class SlidingWindowRateLimiter { private final int maxRequests; private final long windowSizeMs; private final ConcurrentHashMapLong, LongAdder counters new ConcurrentHashMap(); public SlidingWindowRateLimiter(int maxRequests, long windowSizeMs) { this.maxRequests maxRequests; this.windowSizeMs windowSizeMs; } public boolean tryAcquire() { long currentWindow System.currentTimeMillis() / windowSizeMs; counters.computeIfAbsent(currentWindow, k - new LongAdder()).increment(); long count counters.get(currentWindow).sum(); if (count maxRequests) { return false; } counters.entrySet().removeIf(entry - entry.getKey() System.currentTimeMillis() / windowSizeMs - 1); return true; } }这个实现胜在简洁没有引入外部中间件单机限流完全够用。注意事项是旧窗口的清理用了removeIf这是JDK 8里ConcurrentHashMap支持的遍历删除方法它本质上是弱一致性的但清理过期窗口这种场景不要求强一致所以没问题。6. 写在最后的经验真正常用的ConcurrentHashMap方法其实就那几个put、get、putIfAbsent、compute、computeIfAbsent、remove(key, value)。把每个方法的原子性边界搞清楚胜过背十遍源码。如果你在写多线程代码时还在纠结“要不要加锁”下一个动作应该是先想想ConcurrentHashMap能不能解决如果已经用了它但性能依然不理想先检查是不是有大量hash冲突再看是不是自己在外部又包了一层不必要的锁。另外提一句版本的事JDK 8和JDK 11的ConcurrentHashMap实现几乎没有区别但JDK 17在compute方法上做了少量优化。如果你还在维护JDK 8的工程放心用这套知识完全适用。最后一个小技巧排查线上问题需要看某个key是否存在时与其反复get不如直接用compute一步到位还能保证原子性。代码越简洁出问题的面越小。这也是我用了这么多年并发容器最想分享的一句话。
我先说个结论如果你还在用synchronized包HashMap或者自己手写锁来管理缓存那多半还没真正吃透ConcurrentHashMap。这个从JDK 5就存在的并发容器到现在依然是Java并发编程里“既要线程安全、又要高性能”的标准答案Java面试问它线上排查问它连中间件源码里也到处是它的身影。这篇文章我不打算给你背教科书而是以实战视角彻底拆解ConcurrentHashMapJDK 7和JDK 8两代实现的核心差异、put/get/扩容这些高频方法的底层逻辑、日常开发里最容易踩的五个坑以及单机和分布式场景下的选型建议。内容会比较干但绝对能让你在看完之后既能应付面试连环问也能在代码评审和线上问题排查里更有底气。1. 设计思路拆解为什么HashMap不香了又为什么不用全局锁1.1 HashMap的非线程安全到底不安全在哪要理解ConcurrentHashMap存在的意义得先搞清楚HashMap在多线程环境下是怎么“挂”的。JDK 7时代HashMap最著名的死循环问题就是多线程并发put触发扩容多个线程同时操作链表头插法导致链表成环下一次get时CPU直接飙满。JDK 8虽然把头插改成了尾插死循环问题从结构上被消除但数据覆盖、size计数错乱、甚至get到null这些线程安全问题依然存在。比如两个线程同时put不同key恰好落在同一个桶上一个线程写入后另一个线程覆盖了前一个的value最终丢失更新这种问题在缓存场景下尤其隐蔽表面看不出异常但数据就是悄悄错了。所以多线程场景下直接用HashMap基本等于埋雷。但你如果给HashMap外面套一层synchronized或者用Hashtable又会遇到另一个问题所有读写操作都串行化并发越高、性能越差。一个简单的缓存读写QPS稍微上来一点锁竞争就能把CPU空转耗尽。ConcurrentHashMap的思路就很直白不追求绝对无锁而是把锁的粒度做到足够细让大多数操作根本碰不到锁竞争。1.2 JDK 7的分段锁设计JDK 7的ConcurrentHashMap采用分段锁Segment机制。它内部维护一个Segment数组每个Segment继承自ReentrantLock默认16个Segment每个Segment里面又是一个小的HashEntry数组。put一个key时先通过hash定位到某个Segment然后只需要锁住这个Segment其他Segment的读写完全不受影响。这样理论上并发度就是Segment的数量默认16。这种设计在当时已经是很大的进步但有两个明显问题第一Segment数量在构造时定死无法扩容并发量上去了就卡在16路并发第二get操作虽然不加锁但依然要经过两次hash定位先定位Segment再定位桶而且在读的过程中如果正好遇到扩容读到的可能是旧链表的节点一致性偏弱。1.3 JDK 8的CAS synchronized演进JDK 8彻底重写了ConcurrentHashMap放弃Segment改成Node数组 CAS synchronized的组合。这是整个演进里我最欣赏的一次设计直接用CAS处理桶为空的插入只有在桶内已有节点、发生hash冲突时才加synchronized锁住链表头节点或红黑树根节点。这个改动带来三个质变第一锁粒度从Segment级细化为单个桶级并发度从固定16提升到理论上的数组长度级别默认数组长度16实际能抗的并发远远超过JDK 7第二读操作几乎无锁化Node的value和next都用volatile修饰读的时候靠volatile的可见性保证拿到最新值第三扩容支持多线程协助迁移彻底告别了JDK 7扩容时其他线程只能干等的局面。一句话总结JDK 8的ConcurrentHashMap在“并发安全”和“并发性能”之间找到了更好的平衡点这也是它至今仍是并发容器首选的根本原因。2. 核心机制精讲put、get、扩容和计数的底层逻辑2.1 put方法从CAS到synchronized的降级路径put是理解ConcurrentHashMap的钥匙。它的完整流程可以拆成四步第一步计算hash。key的hashCode经过一次扰动函数(h ^ (h 16))把高位信息扩散到低位目的是让hash在数组长度较小时也能尽可能散列均匀减少碰撞。第二步检查数组是否为空。如果table还没初始化就调用initTable()进行懒加载初始化。这里有个细节sizeCtl这个volatile变量承担了初始化锁的职责多个线程同时进入initTable时通过CAS把sizeCtl从0改成-1谁成功谁初始化失败的线程调用Thread.yield()让出CPU直到初始化完成。第三步定位桶。如果定位到的桶下标位置是null直接CAS写入新节点这一步无锁完成也是并发性能最大的来源。第四步如果桶位置已经有节点进入synchronized代码块。这里要判断桶里的节点是普通链表节点、还是树节点TreeBin链表就尾插树就走红黑树的插入逻辑。插入完成后如果链表长度超过TREEIFY_THRESHOLD 8尝试调用treeifyBin转红黑树但转树之前还有个判断如果数组长度小于MIN_TREEIFY_CAPACITY 64优先扩容而不是转树。还有一个容易忽视的细节key和value都禁止为null。这是和HashMap最大的行为差异之一原因很简单——并发容器无法通过返回值区分“key不存在”和“value为null”如果允许nullget返回null时你根本不知道是没找到还是值就是null所以设计上直接禁止从源头消除歧义。2.2 get方法无锁读的关键在于volatileget的流程看起来比put简单得多计算hash定位桶如果是null直接返回null然后遍历链表或红黑树找到匹配节点。但它“无锁却安全”的关键全在Node节点的设计上。Node的val和next字段都是volatile修饰的volatile保证了一个线程的写入对另一个线程立即可见。put线程在synchronized块内修改了节点的valget线程不需要加锁读取时也能看到最新值。不过这里有一个很重要的语义要澄清get看到的“最新”是基于volatile语义的最新而不是基于锁的串行化保证。如果put操作还没执行到“写入val”这一步get读到的就是旧值或null这是正常的线性化行为不是bug。对于大多数缓存读多写少的场景这个强度完全够用。另外一个关于扩容的细节get遇到ForwardingNode扩容标记节点hash值为-1时会跳到扩容后的新数组去继续找。JDK 8的扩容是边迁移边读所以get不会阻塞只是可能在新旧数组之间跳转一次。2.3 扩容机制多线程协助迁移的妙处扩容是ConcurrentHashMap整个设计里最复杂的部分也是很多人源码看不下去的地方。我挑重点讲。触发扩容的条件有两个一是链表长度超过8且数组长度小于64二是元素总数超过sizeCtl阈值sizeCtl 数组长度 * 0.75负载因子。扩容时transfer方法被调用它先把数组长度翻倍保持2的幂次然后从旧数组的最后一个桶开始从后往前迁移。关键来了迁移过程中每迁移完一个桶就在旧数组的该桶位置放入一个ForwardingNodehash值为-1。其他线程执行put或get时如果发现桶是ForwardingNode就会主动加入迁移工作通过CAS竞争分配自己的迁移区间这就是“多线程协助扩容”。扩容期间新插入的数据怎么办put线程看到ForwardingNode后会调用helpTransfer加入迁移或者等迁移完这个桶再写入新数组。迁移完成的桶旧数组位置永远被ForwardingNode占着不会再被写入所以不会出现新旧数组数据不一致的覆盖问题。每次扩容的步长stride默认是N / (CPU核数 * 8)每个线程至少负责16个桶的迁移。这种设计让扩容不再是“一条线程的独角戏”在多核机器上扩容效率提升非常明显。2.4 计数逻辑用LongAdder思路解决并发统计问题ConcurrentHashMap统计元素个数用的不是简单的atomic计数器而是借鉴了LongAdder的思路维护一个baseCount同时维护一个CounterCell[]数组。put成功后先尝试CAS累加baseCount如果竞争失败就随机选一个CounterCell累加。sumCount时把所有CounterCell的值和baseCount加起来。这样做的好处是写多线程竞争计数时大家分散到不同的Cell上降低单点CAS冲突性能比Single AtomicInteger高得多。这个设计在LongAdder类里也能看到本质上是用空间换并发。如果你用map.size()做精确判断比如“缓存超过10000就清理”size()返回的是一个近似值因为求和过程中仍有并发写入。绝大多数场景够用但如果要强一致性的精确值得额外加锁或用其他方案。3. 实操指南并发场景下的使用姿势与性能对比3.1 高频场景的推荐写法ConcurrentHashMap最常用的几个场景我列一下每个都附上推荐写法场景一本地缓存读多写少。直接get判空后put性能足够好但要注意多线程同时put同一个key时value的构造过程会有重复。更优的写法是配合computeIfAbsent让value的构造逻辑也在并发控制下执行。场景二统计计数。比如统计每个用户的请求次数map的key是用户IDvalue是计数器。这种场景推荐用LongAdder作为value而不是AtomicInteger配合compute方法做累加能扛更高的并发。场景三KV存储、需要原子性的复合操作。比如“如果key不存在就写入”“如果value满足条件就替换”用putIfAbsent、replace(k, oldV, newV)这些自带原子语义的方法不要自己get再判断再put那一步拆开就不安全了。场景四异步任务的去重。比如多线程捞取任务时用putIfAbsent把正在处理的任务ID放进去返回值不为null说明别人已经处理了天然防重复。3.2 与HashMap、Hashtable、Collections.synchronizedMap的性能对比我用一个简单的JMH基准测试对比过四种Map在8线程并发写场景下的吞吐结果很有代表性ConcurrentHashMap遥遥领先Collections.synchronizedMap最慢Hashtable和它差不多裸HashMap能跑但数据是错的没有比较意义。容器并发写吞吐锁粒度线程安全适用建议HashMap高但错误无锁不安全单线程或读多写少且可容忍数据丢失Hashtable低全表锁安全遗留代码新代码不建议synchronizedMap最低全表锁安全简单场景低并发可用ConcurrentHashMap最高桶级锁CAS安全绝大多数多线程KV场景首选差距的根本原因就是锁粒度。全表锁意味着任何读写都要排队并发越高排队越严重桶级锁让不同key的读写完全并行只有hash冲突的key才需要竞争同一把锁。3.3 初始化参数容量和并发度怎么设ConcurrentHashMap构造时可以传initialCapacity它内部会计算出一个比传入值大的、最小的2的幂次作为初始数组长度。比如你传20实际初始容量是32传100实际是128。这里有个实践经验如果你能预估出大概的容量一定要设置initialCapacity避免频繁扩容。比如你要缓存10万条配置初始容量直接设10万内部实际是131072扩容次数能省则省。JDK 7时代还有个concurrencyLevel参数用来控制Segment数量JDK 8里它已经退化为一个提示参数不能真的控制并发度。如果你还在网上看到“设置concurrencyLevel提升并发”的帖子那基本是在讲JDK 7的旧设计别照搬到JDK 8。4. 常见问题与排坑实录4.1 坑一size()不是精确值很多人在缓存清理场景里用if (map.size() MAX) doClean()这在并发下是不准的。size()只是sumCount的近似快照两个线程同时执行size()可能会得到略有差异的结果甚至size()执行过程中新put进来的元素没被统计进去。解法要根据场景来如果是TOMCAT这类容器的Session管理允许近似值就直接用如果必须精确可以额外维护一个AtomicInteger自行计数或者干脆换成支持强一致性的数据结构比如用锁保护的TreeMap。4.2 坑二computeIfAbsent的递归死锁陷阱JDK 8新增的computeIfAbsent用起来很爽但有一个官方文档明确点名的坑在computeIfAbsent的映射函数里不能再对同一个map做查询、更新操作会导致死锁或IllegalStateException: Recursive update。我见过一个真实案例有人用ConcurrentHashMap做两级缓存A缓存的value为空时在computeIfAbsent的回调里去查B缓存而B缓存恰好也在用computeIfAbsent回的调里去查A两个线程互相等待直接卡死应用。正确姿势是computeIfAbsent的回调函数里只做“创建value”的事情绝不能再碰同一个map。4.3 坑三迭代器是弱一致性的不允许一边遍历一边修改ConcurrentHashMap的迭代器是弱一致性的它不保证一定能看到迭代过程中新插入的元素也不会抛出ConcurrentModificationException。这个特性在大多数场景是好事但如果你在迭代时直接调用remove或put行为可能和预期不一致。迭代器里有remove方法但它是基于迭代器当前位置的如果你用map.remove(key)这种方式在遍历过程中删除不报错但删除的元素可能仍然被遍历到也可能遍历不到结果不确定。如果你需要“遍历并删除满足条件的元素”推荐先把要删的key收集到一个list里遍历结束后统一调用map.removeAll(keys)。4.4 坑四value不能为null前面提过ConcurrentHashMap的key和value都禁止为null。如果你往里面存null会直接抛NullPointerException。很多从HashMap迁移过来的老代码没注意这个差异。解决方案如果确实需要“null值”的语义用Optional包装一层或者在上层统一约定一个空对象常量替代null。4.5 坑五错误的“先检查后操作”模式看看这段代码if (!map.containsKey(key)) { map.put(key, value); }在并发下这是错误的。两个线程可能同时通过containsKey的检查然后同时执行put后写的覆盖先写的。正确做法是直接用putIfAbsentmap.putIfAbsent(key, value);这个方法的原子性由内部实现保证比“检查后再放”可靠得多。同理“先get再根据结果决定是否删除”也应该改成remove(key, value)的条件删除版本。5. 进阶从源码到面试的真实考题5.1 面试官爱问的为什么链表转红黑树的阈值是8这个问题几乎每次面试都会出现。8这个数字不是拍脑袋定的它来自泊松分布的概率计算。在负载因子0.75、hash随机性良好的前提下同一个桶里出现8个节点的概率大约是千万分之六这个概率已经足够低。或者说链表长度达到8时说明hash分布已经出现严重不均匀此时用红黑树替换链表把O(n)的查询降到O(log n)是合理的性能兜底。同时红黑树节点TreeNode的内存占用是普通链表节点的两倍所以不能一来就转树必须超过8且数组长度达到64才转避免小数组时频繁树化反而浪费内存。5.2 面试官爱问的扩容时其他线程的读写会阻塞吗不会阻塞。读操作会通过ForwardingNode跳到新数组去找数据写操作会参与迁移或者等当前桶迁移完成后再写入新数组。只有正在迁移的那个桶会短暂地处于“半迁移”状态此时对该桶的写操作需要等待一下但这是毫秒级的且一个桶的迁移非常快。JDK 7的扩容则完全不同扩容期间所有读写都会被阻塞因为Segment级的锁把整个分段都锁住了。这也是JDK 8重点优化的原因。5.3 面试官爱问的ConcurrentHashMap能替代Redis做分布式缓存吗这个问题我面试别人时经常问。答案是不能。ConcurrentHashMap的线程安全只限于单个JVM进程内。你部署两台应用服务器每台都有自己的map用户第一次请求打到机器A写入缓存第二次请求负载均衡到机器B数据就miss了。所以跨进程、跨节点的共享缓存依然需要Redis、Caffeine本地缓存 分布式缓存组合等方案。ConcurrentHashMap在单机本地缓存层面是最优解之一但它解决不了分布式一致性问题。5.4 一个综合实战基于ConcurrentHashMap实现本地限流器最后分享一个我自己项目里用过的思路就是用ConcurrentHashMapLongAdder实现一个简单的滑动窗口限流器。核心逻辑是以时间窗口为key窗口内的请求计数为value每来一个请求就在当前窗口的LongAdder上累加超过阈值就拒绝。public class SlidingWindowRateLimiter { private final int maxRequests; private final long windowSizeMs; private final ConcurrentHashMapLong, LongAdder counters new ConcurrentHashMap(); public SlidingWindowRateLimiter(int maxRequests, long windowSizeMs) { this.maxRequests maxRequests; this.windowSizeMs windowSizeMs; } public boolean tryAcquire() { long currentWindow System.currentTimeMillis() / windowSizeMs; counters.computeIfAbsent(currentWindow, k - new LongAdder()).increment(); long count counters.get(currentWindow).sum(); if (count maxRequests) { return false; } counters.entrySet().removeIf(entry - entry.getKey() System.currentTimeMillis() / windowSizeMs - 1); return true; } }这个实现胜在简洁没有引入外部中间件单机限流完全够用。注意事项是旧窗口的清理用了removeIf这是JDK 8里ConcurrentHashMap支持的遍历删除方法它本质上是弱一致性的但清理过期窗口这种场景不要求强一致所以没问题。6. 写在最后的经验真正常用的ConcurrentHashMap方法其实就那几个put、get、putIfAbsent、compute、computeIfAbsent、remove(key, value)。把每个方法的原子性边界搞清楚胜过背十遍源码。如果你在写多线程代码时还在纠结“要不要加锁”下一个动作应该是先想想ConcurrentHashMap能不能解决如果已经用了它但性能依然不理想先检查是不是有大量hash冲突再看是不是自己在外部又包了一层不必要的锁。另外提一句版本的事JDK 8和JDK 11的ConcurrentHashMap实现几乎没有区别但JDK 17在compute方法上做了少量优化。如果你还在维护JDK 8的工程放心用这套知识完全适用。最后一个小技巧排查线上问题需要看某个key是否存在时与其反复get不如直接用compute一步到位还能保证原子性。代码越简洁出问题的面越小。这也是我用了这么多年并发容器最想分享的一句话。
