CopyOnWriteArrayList 在写操作高频时会显著加重 GC 压力，因其每次写操作都需复制整个底层数组生成新对象，导致大量短生命周期对象涌入年轻代，频繁触发 Minor GC 甚至 Promotion Failed 和 Full GC。
CopyOnWriteArrayList 在写操作高频时会显著加重 GC 压力，核心原因在于每次写都创建新数组副本，导致大量短生命周期对象进入年轻代，频繁触发 Minor GC，甚至可能晋升到老年代引发 Full GC。
写操作本质是数组复制，对象生成不可回避
add、set、remove 等写方法都会先复制当前底层数组（Arrays.copyOf），再在新数组上修改，最后用 volatile 引用原子替换。这意味着：
- 每写一次，至少产生一个与原数组等长的新对象（Object[]），以及可能的包装对象（如 Integer）
- 旧数组立即失去强引用，成为待回收对象；若写操作密集（比如每毫秒数次），年轻代 Eden 区很快填满
- 大量小对象快速晋升（尤其是大数组），可能提前触发老年代 GC，影响整体吞吐
高频写场景下 GC 表现典型特征
可通过 JVM 参数（-XX:+PrintGCDetails -Xloggc:gc.log）观察到：
- Minor GC 频率异常升高（如 1–3 秒一次），且每次回收量接近 Eden 容量
- Survivor 区使用率低、对象存活时间短，但仍有部分大数组因空间不足直接分配到老年代（-XX:+UseSerialGC 或 CMS 下更明显）
- GC 日志中频繁出现 “Allocation Failure” 和 “Promotion Failed” 提示
缓解 GC 压力的实用策略
不能靠调大堆或调优 GC 参数治本，关键在于减少不必要的复制：
立即学习“Java免费学习笔记（深入）”；
- 批量写优于逐个写：用 addAll(Collection) 替代多次 add；若需插入多个元素，先收集再一次性提交
- 评估是否真需要线程安全写：若写操作实际由单线程控制（如定时任务刷新缓存），改用 ArrayList + 外部同步更轻量
- 写读比例严重失衡才适用：当写频次超过每秒几十次，尤其伴随大数组（>10k 元素），应考虑替代方案（如 ConcurrentHashMap + CopyOnWriteArraySet 组合、分段锁 List、或读多写少的自定义不可变容器）
- 避免在循环内写：例如 for (x : data) list.add(x) 应改为 list.addAll(data)，防止 N 次复制
替代方案参考（按场景选择）
并非所有“线程安全列表”需求都适合 CopyOnWriteArrayList：
- 写少读多 + 迭代不中断 → 仍可保留，但需监控 GC
- 写较频繁 + 允许迭代弱一致性 → 可用 Collections.synchronizedList(ArrayList) + 手动读写分离锁
- 高并发写 + 读允许稍旧 → 改用 ConcurrentHashMap 存储索引映射，或用 Chronicle Queue 等无 GC 结构
- 实时性要求不高 + 数据可批量更新 → 采用双缓冲（double-buffered list）：前台读旧副本，后台构建新副本，原子切换
