copyonwritearraylist适用于读多写少、写操作不频繁的场景，如监听器列表、配置缓存；其写操作复制整个数组（o(n)），迭代器基于快照导致新元素不可见，读无锁但弱一致性；readwritelock适合需强一致性的读写重场景，但须避免读锁中阻塞操作，否则引发写线程饥饿。
CopyOnWriteArrayList 什么时候真能用上
它只适合读多写少、且写操作不频繁的场景，比如监听器列表、配置项缓存。底层每次写都复制整个数组，写操作时间复杂度是 O(n)，并发写多了反而拖垮性能。
常见错误现象：ConcurrentModificationException 没了，但新线程看不到刚 add 的元素——因为迭代器基于快照，写完后旧迭代器不感知更新。
- 写操作（
add、set、remove）会阻塞所有其他写，但不阻塞读 - 读操作完全无锁，所以吞吐高，但数据不是实时一致的（最终一致）
- 不适合存大对象，复制成本高；也不适合高频写，比如每秒几十次
add
ReadWriteLock 为什么常被误用成“读写都慢”
根本问题在于：没真正释放读锁，或者在读锁里干了不该干的事。比如在 readLock().lock() 之后调用了外部服务、数据库查询、甚至只是 sleep，都会把其他写线程卡死。
使用场景明确：临界资源访问频率高、读写都较重、且读写逻辑可清晰分离（例如本地缓存 + 定期刷新）。
立即学习“Java免费学习笔记（深入）”；
- 必须配对使用
lock()和unlock()，推荐用 try-finally，否则容易锁泄漏 - 读锁可重入，但写锁不允许多个线程同时持有，且写锁会排斥所有读锁
-
ReentrantReadWriteLock默认是非公平的，若写线程一直等不到机会，可能饿死——可显式传true启用公平模式
对比来看，该选哪个不是看“并发”二字，而是看数据一致性要求
CopyOnWriteArrayList 给你的是“读快 + 弱一致性”，ReentrantReadWriteLock 给你的是“可控的一致性 + 可能更重的协调开销”。没有银弹，只有权衡。
典型误判：以为“读多”就一定选 CopyOnWrite。但如果读操作需要强一致性（比如判断某个开关是否已关闭，且后续动作依赖这个判断），那 CopyOnWrite 的延迟就不可接受。
- 需要实时可见性 → 优先考虑
ReadWriteLock或更轻量的volatile+ 不可变对象 - 允许短暂延迟、且写极少 →
CopyOnWriteArrayList简单可靠 - 写操作本身要修改集合内对象状态（而非仅增删元素）→ 两者都不行，得加额外同步或换设计
别忽略 JVM 层面的真实开销
CopyOnWrite 的数组复制会触发大量堆内存分配，GC 压力比想象中大；ReadWriteLock 的锁状态维护和线程调度，在高争用下会产生明显上下文切换开销。压测时别只看吞吐，盯住 GC 日志和 Thread.getState() 分布。
一个容易被忽略的点：JDK 17+ 的 StampedLock 在某些只读占绝对主导的场景下，比 ReadWriteLock 更轻量，但它不支持重入，且乐观读失败后要降级，用错反而更糟。
