copyonwritearraylist仅适用于单线程写、写极少、元素量小（几百内）的读多写少场景；写频次上升或集合变大时会因全量复制导致cpu和gc压力陡增，甚至oom。
读多写少时，CopyOnWriteArrayList 真的适合你吗？
多数人看到“读多写少”第一反应就是 CopyOnWriteArrayList，但它只在特定并发读场景下成立——单线程写 + 多线程读、且写操作极少（比如配置刷新）、元素数量不大（几百以内）。一旦写频次上升或集合变大，add/set 会触发全量数组复制，CPU 和 GC 压力陡增。常见错误现象是压测时写操作 RT 突增 10 倍以上，甚至引发 OutOfMemoryError: GC overhead limit exceeded。
- 适用场景：监听器列表、黑白名单缓存、静态配置项动态更新
- 不适用场景：实时聚合统计、高频状态变更（如订单状态流转中的待处理队列）
- 替代思路：若写操作可批量合并（如每秒一次 flush），用
ArrayList+ 读写锁（ReentrantReadWriteLock）更稳
ConcurrentHashMap 的读性能到底有多高？关键看 key 分布
ConcurrentHashMap 在读多写少场景下往往比 CopyOnWriteArrayList 更通用，因为它的读操作完全无锁（JDK 8+ 使用 Node 数组 + volatile 读）。但前提是 key 的 hashCode() 分布均匀——如果大量 key 落在同一个 bin（比如用时间戳截断为秒级作为 key），会退化成链表遍历，读性能骤降。
- 验证方法：调用
mappingCount()后对比size()，若差距大说明 hash 冲突严重 - 优化建议：重写
hashCode()时避免只依赖单个字段；对时间类 key 可加随机扰动（如timestamp ^ ThreadLocalRandom.current().nextInt()） - 注意：
computeIfAbsent是非原子的“读-判-写”，高并发写仍可能重复初始化，需配合双重检查或putIfAbsent
只读集合封装：用 Collections.unmodifiableXXX 还是自己封装？
如果业务上写操作集中在初始化阶段（如启动时加载全部用户数据），后续纯读，最轻量方案是初始化后转为不可变视图。但 Collections.unmodifiableList(new ArrayList(source)) 本质只是包装一层代理，底层仍可被原始引用修改——这是最容易踩的坑。
- 正确做法：用
new ArrayList(source)先拷贝，再Collections.unmodifiableList()封装 - 更安全选择：Guava 的
ImmutableList.copyOf(source)，它会在构造时深拷贝并冻结内部数组 - 注意点：若元素本身可变（如
Person对象），不可变集合只保证引用不增删，不阻止person.setName()——此时需确保元素类型不可变或手动防御性拷贝
当查询条件不止是 key，还得支持范围/模糊匹配怎么办？
纯 ConcurrentHashMap 只支持 O(1) 精确 key 查找。如果业务需要 “查所有创建时间在某区间内的订单” 或 “查用户名含关键词的用户”，强行用 keySet().stream().filter(...) 会把读多优势全吃掉——每次遍历都是 O(n)。
- 简单解法：按查询维度预建多个
ConcurrentHashMap，比如Map<long order></long>（id）、Map<localdate list>></localdate>（日期分桶） - 进阶方案：引入
TreeMap（天然支持subMap/tailMap）+ 读写锁保护写入，但要注意TreeMap的get是 O(log n)，非严格意义上的“最优” - 真实权衡：这类需求往往意味着该数据已超出集合范畴，该上本地缓存（Caffeine）或嵌入式数据库（SQLite / LevelDB）了
选型没有银弹，核心是盯住两个数字：写操作的吞吐量（QPS）和单次写涉及的数据规模（元素个数 × 平均对象大小）。前者决定能否承受锁开销或复制成本，后者决定内存是否扛得住。很多团队卡在“以为自己读多写少”，结果监控发现每分钟有 200+ 次 add，这时候再聊 CopyOnWriteArrayList 就只是给自己挖坑。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
