线上事故复盘：一次HashMap.remove()引发的关键数据丢失案

事故复盘：多线程共享Map并发操作导致数据丢失

一、背景

在一个分布式服务系统中，我们使用了一个上下文对象（Context）来承载请求链路中的各类参数。该上下文内部维护了一个HashMap<String, Object>用于存储运行时数据，包括业务参数（如nodeId）和性能监控数据（如各阶段的开始时间戳）。

在某次线上巡检中发现，部分请求在执行到下游节点时报错——关键业务参数nodeId丢失，但上游明确已经写入。经排查，问题根因为：耗时统计工具方法在计算完成后调用了HashMap.remove()，在多线程并发场景下触发了 HashMap 的非线程安全行为，导致同一个 Map 中其他 key 的数据被意外丢失或覆盖。

二、原因分析

2.1 问题示例代码

publicclassExecutionContext{/** 使用普通HashMap存储上下文数据 */privateMap<String,Object>contextMap=newHashMap<>();publicMap<String,Object>getContextMap(){returncontextMap;}}publicclassCostTimeUtils{privatestaticfinalStringSTART_TIME_SUFFIX="_start_time";/** * 记录开始时间 */publicstaticvoidrecordStartTime(ExecutionContextctx,Stringkey){ctx.getContextMap().put(key+START_TIME_SUFFIX,System.currentTimeMillis());}/** * 计算耗时并移除开始时间记录 */publicstaticlongcalculateCostTime(ExecutionContextctx,Stringkey){Map<String,Object>map=ctx.getContextMap();StringstartTimeKey=key+START_TIME_SUFFIX;if(map.containsKey(startTimeKey)){longstartTime=(long)map.get(startTimeKey);longcostTime=System.currentTimeMillis()-startTime;// ❌ 危险操作：在共享的HashMap上执行removemap.remove(startTimeKey);returncostTime;}return0L;}}

2.2 执行逻辑

1. 请求进入时，业务线程将nodeId等关键参数写入contextMap
2. 在执行链路中，多个阶段调用recordStartTime()写入耗时起点
3. 各阶段完成后调用calculateCostTime()计算耗时，同时执行map.remove()删除起点记录
4. 后续节点从contextMap中读取nodeId用于业务处理

2.3 并发执行顺序（问题复现场景）

时间线 ──────────────────────────────────────────────────────► 线程A（业务线程） 线程B（异步回调/并行任务） │ │ ├─ put("nodeId", "xxx") │ │ │ ├─ put("step1_start_time", t1) │ │ ├─ put("step2_start_time", t2) │ │ │ ├─ calculateCostTime("step2") │ │ └─ map.remove("step2_start_time") │ │ ⚠️ HashMap内部结构被破坏 │ │ ├─ map.get("nodeId") │ │ └─ 返回 null ❌ │ │ nodeId 已丢失！ │

2.4 根因总结

HashMap是非线程安全的数据结构。当多个线程同时对同一个 HashMap 执行put/remove/get操作时，可能触发以下问题：

本次事故的直接表现是：线程B执行remove()操作时，破坏了 HashMap 的内部结构，导致线程A后续get("nodeId")返回 null。

三、解决方案

方案一：使用 ConcurrentHashMap 替代 HashMap（推荐）

publicclassExecutionContext{/** 使用ConcurrentHashMap保证线程安全 */privateMap<String,Object>contextMap=newConcurrentHashMap<>();}

优点：读写操作天然线程安全，性能优于全局加锁。

方案二：取消 remove 操作，改用不删除的计算方式

publicstaticlongcalculateCostTime(ExecutionContextctx,Stringkey){Map<String,Object>map=ctx.getContextMap();StringstartTimeKey=key+START_TIME_SUFFIX;if(map.containsKey(startTimeKey)){longstartTime=(long)map.get(startTimeKey);// ✅ 只读取，不删除returnSystem.currentTimeMillis()-startTime;}return0L;}

优点：从根本上消除 remove 带来的并发风险；适用于不需要严格清理的场景。

方案三：将清理操作延迟到请求结束统一处理

// 在请求生命周期结束时，由单一线程统一清理publicstaticvoidcleanupAfterRequest(ExecutionContextctx){ctx.getContextMap().entrySet().removeIf(entry->entry.getKey().endsWith(START_TIME_SUFFIX));}

最终采用方案：方案二（不删除开始时间记录），因为耗时统计的临时数据不影响业务，无需即时清理，且改动最小、风险最低。

四、经验总结与注意事项

4.1 共享可变状态是并发 Bug 的温床

如果一个对象会被多个线程访问，且至少有一个线程会修改它，就必须保证线程安全。

4.2 审查清单

4.3 开发规范建议

1. 上下文容器默认使用 ConcurrentHashMap：凡是可能跨线程传递的上下文对象，内部 Map 应默认使用线程安全实现
2. 工具方法遵循最小副作用原则：除非明确需要，工具方法不应修改传入对象的状态
3. 分离读写职责：提供"只读计算"和"清理"两个独立方法，由调用方根据场景选择
4. Code Review 重点关注：对共享对象的remove()、clear()、put()操作，需明确其线程安全性
5. 压测验证：涉及并发修改共享状态的代码，上线前必须进行多线程压测验证

五、时间线