遍历时结构性修改集合会抛ConcurrentModificationException，因modCount与expectedModCount不一致触发fail-fast机制；安全删除须用迭代器remove()、倒序循环、removeIf()或批量移除；修改元素值（非结构变更）是允许的。
Java集合在遍历时直接修改元素（比如调用 list.set(i, newValue)）通常不会出错，但若在迭代过程中结构性修改集合（如 add()、remove()、clear()），绝大多数集合会抛出 ConcurrentModificationException —— 这不是线程安全问题，而是快速失败（fail-fast）机制在起作用。
为什么遍历时删/增元素会报错
ArrayList、HashMap 等集合内部维护一个 modCount（修改计数器），每次结构性修改都会递增它。Iterator 创建时会记录当时的 modCount 值（存为 expectedModCount）。每次调用 next() 或 remove() 时，都会检查两者是否一致。不一致就立即抛异常，防止出现不可预知的行为（如跳过元素、无限循环、数据错乱）。
常见触发场景：
- 用 for-each 循环中调用
list.remove(obj) - 用
Iterator遍历时，调用集合自身的remove()而非迭代器的remove() - 多线程环境下，一个线程遍历，另一个线程修改同一集合（即使用了同步，也可能因未统一锁住而触发）
安全删除元素的正确做法
想边遍历边删，必须使用迭代器提供的 remove() 方法，它是唯一被允许的“遍历中删”方式，会同步更新 expectedModCount。
立即学习“Java免费学习笔记（深入）”；
示例（正确）：
其他可行方式：
- 倒序 for 循环：适用于 ArrayList 等支持随机访问的集合，避免下标错位 for (int i = list.size() - 1; i >= 0; i--) { if (needRemove(list.get(i))) list.remove(i); }
-
收集待删元素，遍历结束后批量删：用临时集合存匹配项，再调
removeAll() - 使用 removeIf()（Java 8+）：语义清晰，内部已做安全处理 list.removeIf(s -> "b".equals(s));
需要修改元素值？可以放心操作
单纯修改元素内容（非结构性变更），不会影响 modCount，完全安全：
-
list.set(i, "new")—— ✅ 允许（ArrayList） -
map.put(key, newValue)—— ✅ 允许（HashMap，key 存在时是替换） -
list.get(i).setName("xxx")—— ✅ 允许（改对象属性，集合结构未变）
⚠️ 注意：如果 set 的是 null 或新对象，且后续逻辑依赖引用关系，需确认业务语义是否合理，但这不属于并发修改异常范畴。
真要并发修改？选对集合类型
如果确实需要多线程边读边写，别强行给非线程安全集合加锁，优先考虑专为并发设计的集合：
-
CopyOnWriteArrayList：读多写少，遍历时写操作不影响当前迭代器（底层复制数组） -
ConcurrentHashMap：支持高并发读写，迭代器弱一致性（不抛 CME，可能看不到最新修改） -
BlockingQueue实现类（如LinkedBlockingQueue）：适合生产者-消费者场景
注意：CopyOnWriteArrayList 迭代器的 remove() 是空操作（不支持），只能用集合自身方法删 —— 但删操作会重建整个数组，代价大，慎用。
基本上就这些。核心就一条：结构性修改交给迭代器或专用方法，别绕开机制硬来。不复杂但容易忽略。
