叙事框架面试题 → 标准答案验证 → 三个翻车现场 → 边界分析 → 升级版答案上篇讲了线程池参数面试和生产场景的落差这篇我们来看另一道高频面试题——ConcurrentHashMap。线程安全标准答案背得滚瓜烂熟但组合操作照样翻车。面试题ConcurrentHashMap 为什么线程安全QConcurrentHashMap 和 HashMap 有什么区别为什么 ConcurrentHashMap 线程安全这道题几乎每次 Java 面试都会出现标准答案也高度统一JDK 7分段锁Segment 数组继承 ReentrantLock默认 16 个 Segment锁粒度粗JDK 8CAS synchronized 锁单个 bin链表/红黑树头节点锁粒度降到数组元素级面试官听到 JDK 7 vs JDK 8 的差异一般就满意了。这道题从《Java 并发编程实战》到各大公司的面试题库答案几乎一字不差。标准答案的隐含假设但如果你把标准答案拆开看它隐含了三个假设你只用单操作——只 put 一个 key、只 get 一个 key、只 remove 一个 key你来决定 JDK 版本——JDK 8 默认JDK 7 是历史你只关心容器本身——不关心调用方怎么编排这些操作三个假设在面试中都被认为是理所当然的。直到生产环境把它们一个个击穿。生产事故线程安全容器也翻车事故一“卖了 5 件只扣了 3 件”陈姐维护的库存服务核心逻辑只有两行intstockcache.get(key);cache.put(key,stock-1);100 个线程同时扣库存。上线第一周正常——并发量低。第二周大促流量进来库存对不上了账面显示还有 3 件实际卖了 5 件。这不是 ConcurrentHashMap 线程不安全——是get和put各自线程安全但它们之间没有原子性。两个线程同时读到stock 3各自减 1 写回2——卖了两件只扣了一件。两个get()之间没有 happens-before 关系所以读到了相同值。面试的标准答案是对的“put 和 get 是线程安全的。”——但你的业务代码不是map.put(key, value)你的代码是map.put(key, map.get(key) - 1)。事故二CPU 100%所有线程卡在 get() 上如果事故一还算温和数据错但服务还在跑事故二是直接宕机。某网关服务JDK 7上线一个月没出过问题。某天 CPU 突然 100%jstack显示所有线程全部停在ConcurrentHashMap.get()上。排查发现服务需要定期刷新缓存大量并发 put 触发了 ConcurrentHashMap 的 resize。JDK 7 的 resize 使用头插法迁移——多线程同时 resize链表形成环get()遍历这个环永远停不下来。JDK 8 换用了 ForwardingNode 做无锁迁移不存在此问题。但问题在于你的依赖 jar 可能还在用 JDK 7 编译的版本。Gateway 本身是 JDK 8但引入的某个中间件客户端依赖了 JDK 7 版本的 ConcurrentHashMap 用法。面试的标准答案也没错——JDK 8 确实没有这个问题。但它没告诉你你的依赖可能悄悄拖着一个 JDK 7。事故三批量写入后 size 对不上第三个事故最隐蔽——数据没丢、服务没挂但报表对不上。批处理任务批量写入 20 万条数据写入完成后读size()cache.putAll(batch);log.info(写入完成总数{},cache.size());// 输出156,842期望 200,000实际 156,842。差了 43,158 条。不是 bug——size()在 JDK 8 中使用CounterCell[]baseCount做近似计数。高并发写入时size()返回的是能快速拿到的最新近似值不是精确的事务计数。但业务方把它当精确值用了下游系统按这个数做结算差了 4 万多。面试的标准答案继续成立——“ConcurrentHashMap 线程安全”。但线程安全不意味着size()是实时精确的。为什么标准答案不够标准答案对在哪✅单操作原子性put(k, v)、get(k)、remove(k)各自是线程安全的——面试说的这个完全正确✅弱一致性迭代迭代器不抛ConcurrentModificationException——对面试说的也正确✅JDK 8 的演进方向对从 Segment 到 CAS synchronized粒度更细、并发度更高——正确标准答案漏了哪漏了什么面试场景生产场景组合操作只问单操作是否安全业务代码全是组合getput、containsKeyput、putAll版本差异默认 JDK 8依赖 jar 可能用 JDK 7 编译间接拖入旧版本size() 语义“size 返回元素数量”近似计数高并发下不准修复手段不讨论compute / putIfAbsent / mappingCount / 外部锁ConcurrentHashMap 安全性的三层边界安全级别1单操作原子性 ✅ ← 面试只问到这 put(k,v)/ get(k)/ remove(k)各自线程安全 安全级别2弱一致性迭代 ✅ ← 面试偶尔问到 迭代器不抛 ConcurrentModificationException 但不保证看到全部最新写入 安全级别3组合操作原子性 ❌ ← 生产踩坑全在这 get put、containsKey put、putAll、size()需要外部同步或使用 compute()/ merge()面试升级版答案第一层基础答案及格线ConcurrentHashMap 用 CAS synchronized 保证线程安全。JDK 7 用分段锁JDK 8 锁粒度降到 bin 级别。大多数候选人到此为止。能答出 JDK 版本差异的算合格。第二层推导边界拉开差距但’线程安全’只保证单操作的原子性。组合操作getput、containsKeyput没有跨操作保证。一个线程 put 完另一个线程 get 能读到——但一个线程 get 然后 put这两个操作之间的窗口另一个线程也能进来。真正的安全边界面试不会考三层——单操作 ✅、弱一致性迭代 ✅、组合操作 ❌。这一步把背结论变成了讲边界。面试官会意识到你不只是刷了八股。第三层生产案例面试加分项结合真实案例讲我之前维护过一个库存服务用 ConcurrentHashMap 做缓存也是标准的 get put 扣库存——上线前压测正常大促流量进来库存对不上。排查发现是 read-modify-write 丢失更新。修复方案把裸 put 改成 compute() 或 merge()保证 read 和 write 的原子性。同时补充了 JDK 版本检查——某个依赖 jar 的 ConcurrentHashMap 用法从 JDK 7 编译过来的修改了依赖版本才解决。同步展示三个事故的修复方案对比第四层监控验证真正的高阶面试官可能追问“修复完你就放心了”不放心。加了三道防线代码审查grep 检查ConcurrentHashMap.*\.get(.*put模式——所有 RMW 都要改成 computeJDK 版本审计mvn dependency:tree检查所有传递依赖的 JDK 版本数据校验重要业务加对账——ConcurrentHashMap 的 size 不用来做业务判断用 mappingCount 做参考生产中这么用安全操作速查场景❌ 面试八股写法✅ 生产正确用法原子增减map.put(k, map.get(k) 1)map.compute(k, (k,v) - vnull ? 1 : v1)不存在时写入if (!map.containsKey(k)) map.put(k, v)map.putIfAbsent(k, v)批量写入后计数map.putAll(batch); map.size()map.putAll(batch); long n map.mappingCount()遍历时删除for (Entry e: map.entrySet()) map.remove(...)map.forEach(2, (k,v) - { map.remove(k); })⚠compute内抛异常会删除该 key——短操作用 compute长业务用外部锁。grep 检查你的项目# 检查 read-modify-write 模式最常翻车grep-rnConcurrentHashMap.*\.get(src/|grep-Eput|remove# 检查裸 check-then-actgrep-rncontainsKey.*ConcurrentHashMapsrc/# 检查传递依赖的 JDK 版本mvn dependency:tree|grepconcurrent# 检查 size() 做业务判断grep-rnConcurrentHashMap.*\.size()src/|grep-vlog\|print“面试题的标准答案只是地图——只有到生产里走一次才知道地图漏了哪条路。”下篇我们聊强/软/弱/虚引用——面试全能背生产 OOM 还是不会查。