线上数据不一致多因Java集合迭代失效，根源在modCount与expectedModCount不匹配；需通过条件断点、共享集合检查、异步调用排查，并依场景选用removeIf、CopyOnWriteArrayList或ConcurrentHashMap等方案。
线上系统出现数据不一致、偶发逻辑错乱，但日志无异常、本地无法复现——这类问题十有八九是集合迭代失效机制在“悄悄作祟”。它不抛错、不崩溃，只让业务结果悄悄偏移，排查难度极高。核心不是“并发”本身，而是 Java 集合的 fail-fast 机制与实际修改行为之间的状态错位。
看懂 modCount 和 expectedModCount 的实际差值
所有问题根源都藏在这两个整数里：modCount 是集合自身的修改计数器，每次 add/remove/resize 都自增；expectedModCount 是迭代器初始化时记下的 modCount 快照。只要两者不等，next() 或 remove() 就会炸。排查时别只盯堆栈，要反向验证：
- 在报 CME 的位置打条件断点，观察 modCount 和迭代器内 expectedModCount 的具体值
- 检查是否有多处代码共用同一个集合实例（比如 Spring Bean 中的 @Autowired List）
- 确认是否有异步线程（如定时任务、MQ 消费者、CompletableFuture）在遍历中途偷偷调了 remove/add
识别“看似安全”的危险写法
很多代码表面没用 foreach，却照样翻车。这些模式在线上高频出现：
- 普通 for 循环删元素 + i++：删除后元素前移，i 却照常加 1，直接跳过下一个元素（例如 [1,2,3,4] 删 2 后变成 [1,3,4]，3 被跳过）
- Stream.filter().collect() 中混用外部可变集合：比如 filter 里调用 list.remove()，或 forEach 里改共享 list
- removeIf 传入非纯函数：lambda 里触发了其他副作用（如远程调用、DB 更新），导致执行时间波动，掩盖了结构修改的本质
用工具缩小嫌疑范围
靠人肉扫代码效率低，推荐三类轻量手段：
立即学习“Java免费学习笔记（深入）”；
- 在关键集合字段上加 final 修饰，编译期拦截非法赋值；若不可行，用 lombok 的 @NonNull + 构造注入约束源头
- JVM 启动参数加 -Dsun.misc.Unsafe.enabled=true（仅限测试环境），配合 Arthas watch 命令监控 ArrayList#remove 方法调用栈
- 对高频使用的 List/Map 封装一层代理类，在 add/remove 前打印 Thread.currentThread().getName() 和堆栈，快速定位“谁在什么时候动了它”
修复必须匹配场景，不能一招鲜
没有银弹，选方案要看读写比例、实时性要求和是否跨线程：
- 单线程遍历删除 → 优先用 removeIf 或 Iterator.remove()，语义明确且 JVM 已深度优化
- 读远多于写、允许短暂脏读 → 改用 CopyOnWriteArrayList，但注意它不适合频繁写场景（每次写都复制全量数组）
- 多线程共享+需强一致性 → 放弃 ArrayList，换成 ConcurrentHashMap 存储，或用 Collections.synchronizedList 并严格包裹迭代块在 synchronized 块内
- 复杂过滤逻辑+不能中断遍历 → 先用新集合收集保留项，最后用 list.clear() + list.addAll(newList) 原子替换
