多线程并发清洗数据时直接修改非线程安全集合会破坏原子性、可见性和迭代一致性，导致数据丢失、覆盖、越界异常、死循环及concurrentmodificationexception，且错误随机难调试。
因为在多线程并发清洗数据时，直接修改非线程安全集合（如 ArrayList、HashMap、HashSet）会同时破坏原子性、可见性和迭代一致性，导致数据丢失、覆盖、越界异常甚至死循环，且错误表现随机、难以复现和调试。
一、结构性修改引发数据错乱
清洗过程常含 add/remove/put 等操作，而这些方法本身不是原子的：
-
ArrayList.add()：先检查容量，再赋值，最后递增 size。两个线程同时判断“容量够”，都往同一索引写入，后写的覆盖前写的；size 被累加两次，最终超出数组长度，后续操作触发
ArrayIndexOutOfBoundsException。 - HashMap.put()：在扩容阶段，多个线程并发 rehash 可能导致链表成环，使 get() 进入无限循环（JDK 7）；JDK 8 虽改用红黑树，但仍可能丢失键值对或产生空指针。
二、遍历中修改触发 ConcurrentModificationException
清洗逻辑常需“边遍历边过滤/转换”，但非线程安全集合的迭代器采用 fail-fast 机制：
- 迭代器初始化时记录
modCount（修改计数），每次调用next()前校验是否匹配； - 只要任一线程调用集合自身的
remove()或add()，modCount就变，当前或另一线程的迭代器立刻抛出ConcurrentModificationException； - 该异常在单线程 foreach 中也会出现，多线程下更频繁、更难定位——你无法确定是哪个线程“偷偷”改了集合。
三、内存可见性导致脏读与丢失更新
清洗结果依赖中间状态（如去重标记、统计计数），而非线程安全集合不保证：
- 线程 A 修改了某个元素的状态（如标记为“已清洗”），该变更可能仅停留在其 CPU 缓存中，线程 B 读到的是旧值；
- 多个线程同时执行
list.removeIf(...)或map.computeIfAbsent(...)，因无同步，彼此看不到对方的修改，造成重复处理或漏处理。
四、没有锁保护，竞态条件必然发生
清洗任务天然具备高并发读写特征（如多线程解析 CSV 行、并行校验字段、批量写入结果），而 ArrayList/HashMap 等类内部完全不加锁：
- 没有 synchronized、没有 volatile 修饰关键字段（如
size、table）、没有 CAS 操作； - 任何看似“简单”的操作（如
list.size() == 0后调用list.get(0)）在多线程下都可能因中间被其他线程修改而失效； - 这不是“概率低”的问题，而是只要并发度足够、运行时间足够长，就一定会暴露。
