如何根据并发量选择线程安全的集合类：Collections.synchronized vs JUC？

本文共计662个文字，预计阅读时间需要3分钟。

选择`Collections.synchronized`还是JUC并发集合，不能仅仅看有没有锁，关键要看实际并发量、读写比和操作类型。低并发、简单场景可以用`synchronized`包装器；中高并发、读多写少或需要原子复合操作时，JUC类更稳定、更高效。

低并发 + 简单读写：Collections.synchronized 足够

适合线程数少（比如 ≤ 5）、操作频次低（每秒增删查总和

• 单个 add、get、put 操作天然线程安全，无需额外同步
• 代码轻量，改造成本低，适合快速适配遗留逻辑
• 注意：遍历时必须显式加 synchronized 块，否则可能抛 ConcurrentModificationException

中高并发 + 读远多于写：优先 CopyOnWriteArrayList / CopyOnWriteArraySet

典型如监听器列表、配置项缓存、白名单集合等——读操作每秒成百上千，但写（增删）一天才几次。

• 读完全无锁，吞吐量高，迭代器绝对安全，不怕边读边改
• 写操作复制整个数组，内存开销和 GC 压力随集合大小线性增长，别用于 > 1000 元素且写较频繁的场景
• 不支持在迭代中修改，但也不需要你操心——它本来就返回快照

读写均衡 + 需要强一致性：ConcurrentHashMap 或 ConcurrentLinkedQueue 是主力

比如共享任务队列、实时计数器、会话状态映射表——读写都频繁，还常需要 putIfAbsent、computeIfPresent 这类原子语义。