在Java开发中，fail-fast（快速失败）和fail-safe（安全失败）是两种针对集合迭代的并发处理机制，核心差异在于“迭代期间遇到并发修改时的处理方式”，这种差异直接决定了两者在性能上的不同表现。

一、fail-fast 与 fail-safe 的核心含义

1.1 fail-fast（快速失败）

fail-fast 是一种“即时校验、快速报错”的机制，核心逻辑是：迭代器遍历集合时，会实时监控集合的修改状态，一旦发现集合被其他线程（或当前线程迭代期间）修改，立即抛出 ConcurrentModificationException 异常，终止迭代操作，避免数据不一致。

典型应用场景：非线程安全集合，如 ArrayList、HashMap、HashSet，这些集合本身不具备并发安全能力，通过fail-fast机制提醒开发者“当前操作存在并发风险”。

底层原理

所有fail-fast集合内部都维护一个 modCount 变量（记录集合修改次数）：

1. 迭代器创建时，会将当前集合的 modCount 赋值给迭代器自身的 expectedModCount；

2. 每次迭代next()方法时，都会校验 modCount 与 expectedModCount 是否相等；

3. 若不相等（说明集合被修改），直接抛出异常，终止迭代。

示例（会触发fail-fast）：

List<String> list = new ArrayList<>();
// 增强for循环本质是迭代器遍历
for (String s : list) {
    list.add("test"); // 迭代期间修改集合 → 抛ConcurrentModificationException
}

1.2 fail-safe（安全失败）

fail-safe 是一种“容错性强、不中断执行”的机制，核心逻辑是：迭代器遍历的不是原集合，而是原集合的“快照（副本）”，即使原集合在迭代期间被修改，也不会影响快照的遍历，因此不会抛出异常，保证迭代操作正常完成。

典型应用场景：线程安全集合，如 CopyOnWriteArrayList、ConcurrentHashMap，这些集合专门为多线程并发场景设计，通过牺牲部分一致性和性能，换取并发安全。

底层原理

fail-safe集合的核心是“读写分离”：

1. 迭代器创建时，会复制一份原集合的副本（快照），迭代操作仅针对副本进行；

2. 原集合的增删改操作，会在新的副本上执行（如CopyOnWriteArrayList会复制新数组），不影响正在遍历的旧副本；

3. 迭代过程中不会做任何修改校验，因此不会抛异常，但可能读到的是旧数据（最终一致性）。

示例（不会触发fail-safe异常）：

List<String> list = new CopyOnWriteArrayList<>();
for (String s : list) {
    list.add("test"); // 迭代期间修改原集合 → 不抛异常，正常遍历
}

二、fail-fast 与 fail-safe 对性能的影响

两者的性能差异，本质是“是否复制副本”“是否做修改校验”“是否支持并发修改”这三个核心差异导致的，具体影响需结合使用场景分析。

2.1 fail-fast 对性能的影响

优点（性能优势明显）

• 无内存拷贝开销：迭代直接操作原集合，不需要额外复制副本，内存占用极低；

• 校验开销极小：仅做 modCount 与 expectedModCount 的数值比较，操作简单、耗时极短；

• 单线程性能最优：在无并发修改的单线程场景下，迭代速度远高于fail-safe集合，无任何额外性能损耗。

缺点（性能/稳定性风险）

• 并发场景易报错：多线程下，一旦有线程修改集合，迭代会立即抛异常，导致业务中断，后续需要重试，间接增加系统开销；

• 需额外加锁保障并发：若要在多线程场景使用fail-fast集合，必须手动加锁（如synchronized），加锁会导致并发吞吐下降，抵消其性能优势；

• 异常处理开销：频繁的ConcurrentModificationException会增加异常捕获、日志打印的性能损耗，影响系统稳定性。

总结

fail-fast 适合单线程、遍历为主、无并发修改的场景，此时性能最优；多线程并发场景下，其稳定性差、需加锁，反而会拉低性能。

2.2 fail-safe 对性能的影响

缺点（性能损耗突出）

• 内存拷贝开销大：迭代时需要复制原集合的副本，大数据量下，副本会占用双倍内存，增加内存压力；

• 写操作性能差：每次增删改操作都会复制新的集合（如CopyOnWriteArrayList复制新数组），频繁写操作会导致CPU占用飙升，性能急剧下降；

• GC压力大：频繁复制集合会产生大量临时对象，触发频繁GC，进一步影响系统性能；

• 数据延迟：迭代的是快照，无法读到迭代期间原集合的最新数据，存在最终一致性问题，部分场景需额外处理数据同步。

优点

• 并发读性能极高：遍历快照时无需加锁，多线程可同时读取，不阻塞、吞吐高；

• 无异常开销：迭代期间允许任意修改原集合，不会抛异常，避免了异常处理的性能损耗，保证业务流程正常执行；

• 并发安全性好：无需手动加锁，集合内部已实现读写分离，适合多线程并发场景。

总结

fail-safe 适合多线程、读多写少的场景（如配置列表、白名单），此时读性能无损耗，牺牲少量内存和写性能换取并发安全；若写操作频繁，其性能会严重下降，不适合此类场景。

三、两者性能对比总表

性能维度	fail-fast	fail-safe
迭代开销	极小（仅数值校验）	较大（需复制快照）
内存占用	低（无副本）	高（存快照，大数据量翻倍）
写操作性能	高（无复制，仅改modCount）	低（频繁复制集合）
并发读性能	一般（无锁但易冲突、报错）	很高（无锁遍历快照）
GC压力	小（无临时对象）	大（频繁产生副本对象）
并发场景适配	差（需加锁，易报错）	好（无需加锁，安全稳定）

四、生产选型性能建议

1. 单线程、普通业务遍历（无并发修改）：优先使用ArrayList、HashMap（fail-fast），性能最优，无额外开销；

2. 多线程、读多写少（如配置缓存、白名单）：使用CopyOnWriteArrayList、ConcurrentHashMap（fail-safe），牺牲少量内存和写性能，换取高并发读性能；

3. 多线程、写操作频繁（如高频插入/删除的业务列表）：避免使用fail-safe的CopyOnWrite系列，改用ConcurrentLinkedQueue或加锁的普通集合，减少拷贝开销；

4. 大数据量集合：优先使用fail-fast集合，搭配手动加锁控制并发，避免fail-safe的快照内存翻倍问题。

五、核心总结

1. fail-fast：迭代原集合，靠modCount校验，并发修改抛异常；单线程性能好，多线程需加锁，性能下降；

2. fail-safe：迭代集合快照，不抛异常，支持并发修改；读并发高，但有拷贝开销、写性能差、内存占用高；

3. 性能核心差异：是否复制副本、是否做修改校验，决定了两者在单线程/多线程、读多写少/写多读少场景下的性能表现。