fail-fast机制通过modcount实时校验并发修改，不一致即抛concurrentmodificationexception；fail-safe机制通过快照或线程安全结构（如copyonwritearraylist、concurrenthashmap）避免异常，保障遍历安全但有内存与一致性代价。
fail-fast 机制：靠 modCount 做实时校验
Java 中 ArrayList、HashMap 等非线程安全集合采用 fail-fast，核心是维护一个 modCount（修改计数器）。每次 add、remove、clear 等结构性修改操作，modCount 就加 1。当调用 iterator() 获取迭代器时，迭代器会把当前 modCount 复制到自己的 expectedModCount 字段中。后续每次调用 next() 或 remove() 前，都会检查 modCount 是否仍等于 expectedModCount。
一旦不等，说明集合在迭代期间被外部修改了——可能是另一个线程改的，也可能是当前线程用集合自身的 remove() 而非迭代器的 remove() 改的。此时立即抛出 ConcurrentModificationException，不继续遍历。
这种设计不是为了“处理并发”，而是为了“暴露不一致”。它让错误在发生点立刻浮现，避免程序基于已损坏的集合状态继续运行。
fail-safe 机制：靠副本隔离读写冲突
CopyOnWriteArrayList、ConcurrentHashMap 等类采用 fail-safe。它们不依赖 modCount 校验，而是从根本上规避结构冲突：写操作（如 add、remove）时，先复制当前底层数组或哈希表的完整副本，在副本上修改，再用 CAS 或 volatile 引用原子替换原引用。
这样一来，正在执行的迭代器持有的仍是旧数组/旧哈希表的引用，不受新写入影响。所以即使其他线程一边遍历、一边增删，迭代器既不会抛异常，也不会看到新增元素（对 CopyOnWriteArrayList 来说），但能保证遍历过程绝对安全。
代价也很明显：每次写都要复制整个结构，内存开销大；迭代器看到的是“快照”，无法反映最新变更。
单线程下也会触发 fail-fast？是的，很常见
很多人误以为 fail-fast 只在多线程才出现，其实单线程写错方式一样会爆异常。典型场景包括：
- 用 for-each 遍历时，直接调用 list.remove() 删除元素
- 用 Iterator 遍历时，调用 list.add() 插入元素（而非 iterator.remove()）
- 在遍历中嵌套调用另一个会修改该集合的方法
这些操作都会导致 modCount 变化，而迭代器没参与同步更新 expectedModCount，校验失败即抛异常。
怎么选：看读写比例和一致性要求
如果遍历远多于修改（比如配置列表、监听器集合），且能接受“最终一致性”，CopyOnWriteArrayList 是典型的 fail-safe 选择；
如果读写频繁且需要强一致性（比如缓存、任务队列），ConcurrentHashMap 更合适——它通过分段锁 + CAS + Node 链表/红黑树迁移实现更细粒度的 fail-safe 行为；
如果只是普通业务逻辑、无并发需求，用 ArrayList + 迭代器 remove() 或 collect(Collectors.toList()) 过滤更轻量，无需引入 JUC 类。
