CopyOnWriteArrayList的GC压力源于写操作的数组复制，而非迭代器本身；每次add/remove/set均创建新数组并保留旧数组，导致瞬时内存翻倍、Minor GC频发，且活跃迭代器会延长旧数组的GC等待时间。
CopyOnWriteArrayList 的 fail-safe 迭代器本身不造成 GC 压力，真正拖垮堆内存和触发频繁 GC 的，是写操作引发的数组复制行为——每次 add、remove 或 set 都会生成一个新数组，旧数组立即“退役”，但不会立刻回收。
每次写操作都带来两倍瞬时内存占用
写入时，JVM 必须分配一个长度为 n+1（或 n−1）的新数组，并将全部 n 个引用逐个拷贝过去。此时新旧两个数组同时存在于堆中：
- 若原数组含 50 万个 String 引用，单次 add 就额外申请约 50 万 × 8 字节（64 位 JVM）≈ 4MB 内存
- 若每秒写入 10 次，峰值堆内存每秒新增约 40MB，且旧数组需等待 GC 回收
- Young Gen 很快填满，Minor GC 频率显著上升；若对象存活时间稍长，还可能提前晋升到 Old Gen
迭代器快照加剧“隐性内存滞留”
fail-safe 的本质是迭代器持有数组快照引用，这在写频繁场景下会放大内存压力：
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
- 一个长期运行的 for-each 循环（如事件监听器遍历），只要迭代器未被回收，它持有的旧数组就无法被 GC
- 若每秒触发 100 次写操作，同时有 5 个活跃迭代器，就可能堆积 500 个待回收数组副本
- 用 MAT 查看堆转储时，常看到大量
CopyOnWriteArrayList$COWIterator持有已过期的Object[]，GC Roots 清晰可见
写操作串行化放大 GC 尖峰效应
所有写操作必须获取同一把 ReentrantLock，导致高并发写入不是“慢”，而是“排队等复制”：
立即学习“Java免费学习笔记（深入）”；
- 线程 A 正在 memcpy 100 万条引用（耗时几十毫秒），B/C/D 全在锁外等待
- 一旦 A 完成并释放锁，B 立即开始新一轮复制——旧数组刚进 GC 队列，新数组又来了
- jstat 观察可发现 YGCT（Young GC 时间）随写频次阶梯式跳升，甚至出现连续多次 GC
规避高频写带来的 GC 风险
不能靠调大堆或强制 System.gc() 解决，关键在设计层面收敛写行为：
- 避免循环内调用 add：改用批量构造新列表后整体替换（
list = new CopyOnWriteArrayList(newData)） - 写操作合并：比如定时聚合变更，每 100ms 合并一次再刷入，而非逐条 add
- 读写分离更彻底：写端用普通 ArrayList + 显式加锁，读端定期快照同步到 CopyOnWriteArrayList
- 监控指标：重点关注 jstat 输出中的 OU（Old Used）、YGCT 和堆中
Object[]实例数趋势
