concurrenthashmap等并发集合专为多线程写入设计，通过分段锁或cas实现高吞吐，读操作无锁；copyonwritearraylist适用于读多写少场景；concurrentlinkedqueue基于cas无锁，但size()等方法非强一致。
Java 的 java.util.concurrent 包里那些集合（比如 ConcurrentHashMap、CopyOnWriteArrayList、ConcurrentLinkedQueue）不是为了“替代”普通集合，而是为了解决明确的并发写入场景——当多个线程同时修改数据时，它们能避免锁整个集合，也不依赖外部同步，性能和安全性更可控。
为什么不能直接用 HashMap + synchronized？
加锁虽安全，但代价高：所有读写操作串行化，吞吐量断崖式下降；而 ConcurrentHashMap 把桶数组分段加锁（JDK 8+ 改为 CAS + synchronized 锁单个 Node），读操作甚至完全无锁。实测在中高并发写场景下，吞吐量通常是同步包装版的 3–10 倍。
- 普通
Collections.synchronizedMap(new HashMap())：每次get()或put()都锁整个 map，读也阻塞其他读 -
ConcurrentHashMap：get()不加锁（基于 volatile 语义保证可见性），put()只锁对应 hash 桶的头节点 - 注意：
size()和isEmpty()不是强一致性结果，返回的是近似值（因多段状态可能不同步）
CopyOnWriteArrayList 适合什么场景？
它用“读不加锁、写时复制整个数组”的策略，适合读远多于写的场景（比如监听器列表、配置项快照）。但每次写操作都要复制整个底层数组，内存和 GC 压力大，绝对不适合高频写或大数据量。
- 典型误用：把它当普通列表存日志、缓存实时数据 —— 写一次就复制几 MB 数组，很快 OOM
- 正确姿势：管理几十个固定生命周期的回调对象，且极少增删
-
iterator()返回的迭代器是快照，遍历时即使原列表被修改，也不会抛ConcurrentModificationException，但看不到新元素
ConcurrentLinkedQueue 的无锁特性怎么体现？
它基于 CAS 实现，没有内置锁，所有操作（offer()、poll()、peek()）都是非阻塞的。适合高吞吐、低延迟的生产者-消费者模型，但要注意：它不保证弱一致性 —— 比如 size() 可能不准，contains() 是 O(n) 且结果可能过期。
立即学习“Java免费学习笔记（深入）”；
- 不要用
size() == 0判断队列为空，应改用poll() != null或结合业务逻辑判断 - 它不支持
null元素，插入null会直接抛NullPointerException - 和
ArrayBlockingQueue不同，它没有容量限制，但失控增长会导致内存溢出
// 示例：ConcurrentHashMap 的安全复合操作（避免先 get 再 put 的竞态）
ConcurrentHashMap<String, Long> counter = new ConcurrentHashMap<>();
counter.compute("request_count", (k, v) -> (v == null) ? 1L : v + 1L);
真正容易被忽略的点是：这些集合只保证自身操作的线程安全，不解决业务逻辑的原子性。比如“检查 key 是否存在，再 put”，仍需用 computeIfAbsent 或 putIfAbsent 这类原子方法，而不是拆成两步调用 —— 否则再并发的集合也救不了你。
