copyonwrite容器高频写入时性能急剧下降，因每次写操作均需复制整个数组，时间复杂度o(n)，引发严重内存与gc压力、写锁竞争加剧及数据可见性延迟。
写操作频繁时，CopyOnWrite 容器（如 CopyOnWriteArrayList 和 CopyOnWriteArraySet）会迅速暴露性能瓶颈，核心问题不在“线程安全”本身，而在于其底层机制与高频写入的天然冲突。
每次写都复制整个数组
所有可变操作（add、remove、set、clear、addAll）都会触发一次完整底层数组复制：
→ 调用 Arrays.copyOf 创建新数组
→ 将原数组内容逐个拷贝过去
→ 在新数组上完成修改
→ 用 volatile 引用原子替换旧数组
这意味着：
- 时间复杂度恒为 O(n)，与当前元素数量成正比；10 万元素的列表每次
add都要拷贝 10 万个引用 - 即使只增删一个元素，也要付出全量复制代价
- 连续 N 次
add，就产生 N 个新数组副本，旧数组立即变为垃圾对象
内存与 GC 压力陡增
高频写导致大量短生命周期大对象涌入年轻代：
- 每个新数组都是独立对象，大小与集合当前容量一致（例如：一个含 50k String 的数组，仅数组对象就占约 400KB）
- Eden 区快速填满，Minor GC 频率飙升（实测中每秒数次很常见）
- 大数组因 Survivor 空间不足，直接分配到老年代（尤其开启
-XX:+UseSerialGC或 CMS 时） - 日志中频繁出现 “Allocation Failure” 和 “Promotion Failed”，最终可能触发 Full GC
写操作串行化 + 锁竞争加剧
虽然读不加锁，但所有写操作必须获取同一把 ReentrantLock：
- 写线程越多、写越密集，锁等待时间越长，吞吐不升反降
- 复制过程本身耗时，进一步拉长持锁时间，放大排队效应
- 无法像
ConcurrentHashMap那样通过分段或 CAS 实现写并行
数据可见性延迟被放大
写操作不是实时生效，而是“替换引用”的瞬间才对后续读可见：
- 两次写之间若有大量读请求，会持续读到同一个旧快照，延迟不可控
- 在监控类、状态同步等场景中，这种“最终一致性”可能引发逻辑误判
- 迭代器基于创建时刻的快照，写入后立刻遍历仍看不到新数据——高频写下这种滞后更明显且更难调试
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
