Java中fail-fast机制不拦截Stack.pop()，仅在迭代时检测：pop会增加Vector的modCount，导致next()抛ConcurrentModificationException；规避方式包括索引遍历、临时集合、加锁等。
Java 中的 fail-fast 机制本身并不直接拦截 Stack.pop() 操作，它只作用于集合的 Iterator 迭代过程。当通过迭代器遍历 Stack（底层是 Vector）时，若在迭代过程中调用 pop()（或 push()、remove() 等结构性修改方法），会触发 ConcurrentModificationException。
fail-fast 的触发条件
Stack 继承自 Vector，而 Vector 的迭代器是典型的 fail-fast 实现。其核心依赖两个关键字段：
- modCount：记录集合结构性修改次数（如 add、remove、pop、clear）
- expectedModCount：迭代器创建时记录的 modCount 快照值
每次调用 iterator.next() 前，都会检查两者是否一致。一旦 pop() 导致 modCount 变更，而迭代器未同步更新 expectedModCount，下一次 next() 就抛出异常。
Stack.pop() 为何算作结构性修改
尽管 pop() 是栈顶元素移除，逻辑上类似 remove(size()-1)，但它内部调用了父类 Vector 的 removeElementAt()，该方法会递增 modCount。因此对迭代器而言，这与直接调用 remove() 效果相同，属于被监控的“结构变更”。
立即学习“Java免费学习笔记（深入）”；
规避 ConcurrentModificationException 的常见方式
若需边遍历边弹栈，不能依赖普通 Iterator，可考虑以下方案：
- 改用 for 循环索引访问：通过
stack.get(i)和stack.size()控制，避免创建迭代器 - 使用 临时集合暂存待处理元素：先遍历读取所有元素到新 List，再对原 Stack 批量 pop
- 改用 线程安全且非 fail-fast 的替代结构：如
CopyOnWriteArrayList（但注意它不支持栈语义，且开销大） - 加锁 + 手动控制：在 synchronized 块中完成遍历和 pop，确保单线程修改
注意：fail-fast 不是线程安全保证
该机制仅用于检测单线程内非法并发修改，不是为多线程设计的同步机制。即使没有异常，多线程直接操作 Stack 仍可能导致数据错乱。真正需要线程安全栈时，应使用 java.util.concurrent.ConcurrentLinkedDeque 或加锁封装。
