后端开发中，迭代器失效和并发修改导致的安全异常，本质上是多线程环境下共享集合数据被同时读写时产生的不可预测行为。最典型的表现就是Java中的ConcurrentModificationException、C#中的InvalidOperationException，以及Python中的RuntimeError。解决这类问题的核心思路有三条：使用线程安全的集合类、在遍历时加锁、或者采用快照机制复制数据后再遍历。下面我会把每种方案的原理、适用场景和具体代码全部讲透。
一、迭代器失效到底是怎么回事
迭代器失效指的是，当你正在用迭代器遍历一个集合的时候，另一个线程或者同一个线程的另一段代码突然修改了这个集合的结构（比如添加、删除元素），导致迭代器内部维护的索引指针和集合的实际状态对不上了。这时候迭代器就不知道下一步该指向哪里，程序就会抛出异常或者产生脏数据。
举个最简单的例子，Java的ArrayList在单线程下如果边遍历边删除，就会触发fail-fast机制：
List<String> list = new ArrayList<>();
list.add("A");
list.add("B");
list.add("C");
for (String item : list) {
if (item.equals("B")) {
list.remove(item); // 直接在for-each中删除，触发ConcurrentModificationException
}
}
这个异常不是随机出现的，它是JVM在迭代器内部维护了一个modCount字段，每次结构性修改都会让modCount加一。迭代器在每次next()调用时都会检查这个值，发现不一致就立刻报错。这种机制叫fail-fast，好处是快速暴露问题，坏处是在高并发场景下会导致大量异常抛出，影响性能。
二、并发修改为什么比单线程更危险
单线程下的迭代器失效至少是可复现、可调试的。但在多线程环境下，问题会严重得多。两个线程同时操作同一个HashMap，一个在遍历，一个在put新键值对，可能导致以下几种后果：第一，抛出ConcurrentModificationException；第二，遍历到重复元素或跳过某些元素；第三，在极端情况下进入死循环；第四，数据静默损坏，程序不报错但结果是错的。
最危险的是第四种。因为有些集合类不是fail-fast的，比如Java的ConcurrentHashMap的迭代器是弱一致性的，它不会抛异常，但你遍历到的数据可能是某个时间点的快照，不反映最新状态。这在金融、订单这类对数据准确性要求极高的场景下是致命的。
三、解决方案一：使用线程安全的集合类
最直接的办法就是换掉不安全的集合。Java中，HashMap换成ConcurrentHashMap，ArrayList换成CopyOnWriteArrayList，HashSet换成ConcurrentHashMap.newKeySet()。这些类内部通过分段锁、CAS操作或者写时复制机制保证了线程安全。
CopyOnWriteArrayList的原理是每次写操作都会复制一份底层数组，读操作在旧数组上进行，完全不加锁。适合读多写少的场景：
List<String> safeList = new CopyOnWriteArrayList<>();
safeList.add("A");
safeList.add("B");
safeList.add("C");
for (String item : safeList) {
if (item.equals("B")) {
safeList.remove(item); // 安全，不会抛异常
}
}
但要注意，CopyOnWriteArrayList的写操作代价很高，每次修改都要复制整个数组。如果你的集合有上万个元素且写操作频繁，性能会急剧下降。这时候应该用ConcurrentHashMap或者手动加锁。
C#中对应的方案是使用ConcurrentBag、ConcurrentDictionary或者在遍历时用lock包裹。Python中可以用queue.Queue或者threading.Lock配合list使用。
四、解决方案二：显式加锁控制访问
如果你不能换集合类（比如遗留代码、第三方库返回的集合），那就必须用锁来保证同一时刻只有一个线程在访问集合。Java中用synchronized或者ReentrantLock：
List<String> list = new ArrayList<>();
ReentrantLock lock = new ReentrantLock();
// 线程A：遍历
lock.lock();
try {
for (String item : list) {
System.out.println(item);
}
} finally {
lock.unlock();
}
// 线程B：修改
lock.lock();
try {
list.add("D");
} finally {
lock.unlock();
}
这种方式的优点是简单可靠，缺点是锁的粒度太粗会导致性能瓶颈。更好的做法是用读写锁ReadWriteLock，允许多个读线程同时访问，写线程独占：
ReadWriteLock rwLock = new ReentrantReadWriteLock();
// 读操作
rwLock.readLock().lock();
try {
for (String item : list) {
System.out.println(item);
}
} finally {
rwLock.readLock().unlock();
}
// 写操作
rwLock.writeLock().lock();
try {
list.add("D");
} finally {
rwLock.writeLock().unlock();
}
五、解决方案三：快照与防御性复制
如果你的业务逻辑允许遍历的数据不是绝对实时的，那最安全的做法是在遍历前复制一份集合。Java中可以用Collections.synchronizedList配合toArray，或者直接new一个新集合：
List<String> original = getSharedList();
List<String> snapshot = new ArrayList<>(original);
for (String item : snapshot) {
// 对snapshot的操作不会影响original
process(item);
}
这种方式的好处是完全避免了并发问题，坏处是如果集合很大，复制开销不小，而且快照数据有延迟。在实时性要求不高的报表生成、日志分析场景下非常实用。
Python中可以用list()或者copy.deepcopy()实现同样效果。Go语言中由于没有内置的线程安全map，通常需要自己用sync.RWMutex包裹map，或者在遍历时先把所有key收集到slice中再逐个访问。
六、不同语言的具体表现和最佳实践
Java：ArrayList和HashMap是fail-fast的，ConcurrentHashMap是弱一致性的，CopyOnWriteArrayList是写时复制的。生产环境中，如果集合会被多线程访问，默认就应该用Concurrent开头的类，不要心存侥幸。
C#：List和Dictionary在多线程下不安全。使用ConcurrentDictionary、ConcurrentBag，或者用lock语句块包裹所有访问。C# 8.0之后还有System.Collections.Concurrent命名空间下的一系列类型可以直接用。
Python：由于GIL的存在，单进程下的多线程不会真正并行执行CPU密集型代码，但迭代器失效问题依然存在，尤其是在I/O密集型场景下线程切换时。解决办法是用threading.Lock，或者用multiprocessing.Manager提供的共享列表。
Go：map本身不是线程安全的，并发读写必须加sync.RWMutex。range遍历map时如果另一个goroutine在写，会直接panic。正确做法是加锁或者用sync.Map。
七、实际开发中容易踩的坑
第一个坑：以为用了ConcurrentHashMap就万事大吉。ConcurrentHashMap的迭代器不抛异常，但你在遍历过程中如果同时有其他线程在put，遍历结果可能不包含新数据也可能包含已删除的数据。如果业务要求遍历期间数据完全稳定，还是得加锁。
第二个坑：在Spring等框架中，Service层的成员变量如果是普通的ArrayList或HashMap，多个请求同时访问就会出问题。很多人把集合定义成实例变量而不是方法内局部变量，这是非常常见的并发bug来源。解决办法是每次请求都new一个新集合，或者用ThreadLocal。
第三个坑：嵌套集合的并发问题。比如一个Map里面存的value是List，你在遍历外层Map的value时修改了内层List，同样会出问题。这种情况需要对每一层都做好同步控制。
八、总结与选型建议
面对迭代器失效和并发修改的安全异常，没有万能方案，只有最适合场景的方案。读多写少用CopyOnWrite类或快照复制；写多读少用ConcurrentHashMap加分段锁；对数据一致性要求极高用显式锁或读写锁；遗留代码改造优先加锁再考虑重构集合类型。核心原则就一条：共享可变状态是并发问题的根源，能不共享就不共享，必须共享就做好同步。
后端开发语言迭代器失效与并发修改的安全异常看似是小问题，但在高并发系统中它会被放大成数据错乱、服务崩溃甚至资损事故。把这篇文章里的方案吃透，在实际项目中根据业务特点选对策略，就能从根本上规避这类风险。
