引发的关键数据丢失案)
事故复盘多线程共享Map并发操作导致数据丢失一、背景在一个分布式服务系统中我们使用了一个上下文对象Context来承载请求链路中的各类参数。该上下文内部维护了一个HashMapString, Object用于存储运行时数据包括业务参数如nodeId和性能监控数据如各阶段的开始时间戳。在某次线上巡检中发现部分请求在执行到下游节点时报错——关键业务参数nodeId丢失但上游明确已经写入。经排查问题根因为耗时统计工具方法在计算完成后调用了HashMap.remove()在多线程并发场景下触发了 HashMap 的非线程安全行为导致同一个 Map 中其他 key 的数据被意外丢失或覆盖。二、原因分析2.1 问题示例代码publicclassExecutionContext{/** 使用普通HashMap存储上下文数据 */privateMapString,ObjectcontextMapnewHashMap();publicMapString,ObjectgetContextMap(){returncontextMap;}}publicclassCostTimeUtils{privatestaticfinalStringSTART_TIME_SUFFIX_start_time;/** * 记录开始时间 */publicstaticvoidrecordStartTime(ExecutionContextctx,Stringkey){ctx.getContextMap().put(keySTART_TIME_SUFFIX,System.currentTimeMillis());}/** * 计算耗时并移除开始时间记录 */publicstaticlongcalculateCostTime(ExecutionContextctx,Stringkey){MapString,Objectmapctx.getContextMap();StringstartTimeKeykeySTART_TIME_SUFFIX;if(map.containsKey(startTimeKey)){longstartTime(long)map.get(startTimeKey);longcostTimeSystem.currentTimeMillis()-startTime;// ❌ 危险操作在共享的HashMap上执行removemap.remove(startTimeKey);returncostTime;}return0L;}}2.2 执行逻辑请求进入时业务线程将nodeId等关键参数写入contextMap在执行链路中多个阶段调用recordStartTime()写入耗时起点各阶段完成后调用calculateCostTime()计算耗时同时执行map.remove()删除起点记录后续节点从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操作时可能触发以下问题问题说明数据丢失并发扩容或链表/红黑树操作导致节点丢失死循环JDK7并发 rehash 导致链表成环脏读一个线程的写入对另一个线程不可见结构性破坏remove 操作改变了内部数组结构影响其他 key 的定位本次事故的直接表现是线程B执行remove()操作时破坏了 HashMap 的内部结构导致线程A后续get(nodeId)返回 null。三、解决方案方案一使用 ConcurrentHashMap 替代 HashMap推荐publicclassExecutionContext{/** 使用ConcurrentHashMap保证线程安全 */privateMapString,ObjectcontextMapnewConcurrentHashMap();}优点读写操作天然线程安全性能优于全局加锁。方案二取消 remove 操作改用不删除的计算方式publicstaticlongcalculateCostTime(ExecutionContextctx,Stringkey){MapString,Objectmapctx.getContextMap();StringstartTimeKeykeySTART_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 审查清单检查项说明上下文对象是否跨线程传递如果是内部容器必须线程安全工具方法是否有副作用写/删有副作用的方法在并发场景下格外危险HashMap 是否被多线程共享共享场景必须替换为 ConcurrentHashMap 或加锁remove 操作是否必要优先考虑不删除策略降低并发风险4.3 开发规范建议上下文容器默认使用 ConcurrentHashMap凡是可能跨线程传递的上下文对象内部 Map 应默认使用线程安全实现工具方法遵循最小副作用原则除非明确需要工具方法不应修改传入对象的状态分离读写职责提供只读计算和清理两个独立方法由调用方根据场景选择Code Review 重点关注对共享对象的remove()、clear()、put()操作需明确其线程安全性压测验证涉及并发修改共享状态的代码上线前必须进行多线程压测验证五、时间线时间事件发现问题监控告警发现部分请求缺少 nodeId 参数定位原因排查到耗时统计工具的 remove 操作在并发场景下破坏了 HashMap 结构修复上线将 calculateCostTime 改为不删除模式消除并发写入风险验证通过修复后持续观察nodeId 丢失问题不再复现
