增强for循环遍历集合时修改集合会抛ConcurrentModificationException——因迭代器为fail-fast机制，modCount校验失败即抛异常；安全做法是用Iterator.remove()或removeIf()，并发场景需用ConcurrentHashMap、CopyOnWriteArrayList或加锁。
增强for循环遍历集合时修改集合会抛 ConcurrentModificationException
不安全——只要在增强for循环（即 for (T item : collection)）中调用 collection.remove()、collection.add() 或任何结构性修改方法，几乎必然触发 ConcurrentModificationException。这是因为增强for底层依赖 Iterator，而Java集合（如 ArrayList、HashMap 的 keySet/valueCollection）的迭代器默认是「快速失败」（fail-fast）的。
常见错误场景：
- 想边遍历边删满足条件的元素，直接写
list.remove(item) - 在循环内调用
map.keySet().remove(...)或map.remove(key) - 多线程环境下，一个线程用增强for遍历，另一个线程修改集合
这不是“偶发”，而是设计使然：迭代器在创建时记录集合的 modCount，每次调用 next() 前校验是否匹配；一旦集合被非迭代器方式修改，校验失败即抛异常。
安全删除的正确做法：用 Iterator.remove()
必须显式获取迭代器，并只通过其 remove() 方法删除当前元素。这是唯一被允许的「遍历中删除」方式，且线程不安全（仍需外部同步）。
立即学习“Java免费学习笔记（深入）”；
Iterator<String> it = list.iterator();
while (it.hasNext()) {
String s = it.next();
if (s.startsWith("tmp")) {
it.remove(); // ✅ 安全
}
}
对比错误写法：
分析 Java Spring Boot 后端 Controller 代码，自动生成 Markdown 格式的接口文档。当用户说“生成 Java 接口文档”、“生成 API 文档”、“从 Spring 代码生成文档”时触发。
// ❌ 抛 ConcurrentModificationException
for (String s : list) {
if (s.startsWith("tmp")) {
list.remove(s); // 错误：绕过迭代器
}
}
注意点：
-
Iterator.remove()只能调用一次，且必须紧跟在next()之后 - 不能用于
for-each语法糖，必须手动写while + iterator -
CopyOnWriteArrayList是例外：它的迭代器基于快照，允许遍历时修改原集合，但代价是写操作复制整个数组，适合读多写少场景
removeIf() 是更简洁安全的替代方案（Java 8+）
如果目标只是按条件删除，Collection.removeIf(Predicate) 内部已封装了安全的迭代逻辑，语义清晰且无需手写迭代器。
list.removeIf(s -> s.startsWith("tmp")); // ✅ 线程不安全但遍历安全
map.keySet().removeIf(k -> k == null); // ✅ 同样适用
map.values().removeIf(v -> v == null); // ✅
原理上它仍使用迭代器并调用 it.remove()，但对开发者透明。优势在于：
- 一行代码替代多行循环
- 避免手误调用
collection.remove() - 所有标准集合（
ArrayList、HashSet、LinkedHashMap等）都支持 - 但注意：它不是原子操作，多线程下仍需同步
并发场景下必须换用线程安全集合或加锁
增强for本身不提供线程安全保证。即使你用 Iterator.remove() 或 removeIf()，若其他线程同时修改同一集合，依然可能出错。
可行方案：
- 用
ConcurrentHashMap：它的keySet()、values()、entrySet()迭代器是弱一致性的，不抛ConcurrentModificationException，但可能反映某次修改前的状态 - 用
CopyOnWriteArrayList：适合遍历远多于修改的场景，但内存和性能开销大 - 手动加锁：对整个集合操作块加
synchronized或用ReentrantLock，确保遍历与修改互斥
切记：Vector 和 Hashtable 虽然方法加了 synchronized，但它们的增强for仍会因迭代器检查 modCount 而失败——因为同步只保护单个方法，不保护「遍历+删除」这一复合操作的原子性。
