并发容器通过分段锁、CAS、写时复制等机制实现高效线程安全，避免普通容器的死循环、数据丢失等问题；ConcurrentHashMap 等专为高并发优化，但复合操作仍需注意原子性。
并发容器是 Java 专为多线程环境设计的线程安全集合类，它们不是靠“给整个容器加一把大锁”来保证安全，而是通过分段锁、CAS、写时复制等机制，在保障数据一致性的同时，显著减少线程竞争——换句话说：ConcurrentHashMap 不会因为一个线程在改 "user_100" 就让另一个线程读 "user_200" 等半天。
为什么不能直接用 HashMap 或 ArrayList？
普通容器没有内置同步机制。多个线程同时调用 put() 可能导致链表成环（JDK7 及以前的 HashMap 死循环）、数据覆盖或 ConcurrentModificationException；ArrayList 的 add() 在扩容时若被并发执行，可能引发数组越界或元素丢失。
- 现象：多线程往
new ArrayList()里反复add()，程序偶尔抛ConcurrentModificationException或打印出长度远小于预期 - 错觉：“我用了
Vector/Hashtable就万事大吉”——但它们所有方法都用synchronized修饰，读写串行化，吞吐量差，且复合操作（如“若不存在则 put”）仍需手动加锁 - 替代方案：优先选
ConcurrentHashMap、CopyOnWriteArrayList、ConcurrentLinkedQueue等真正为并发优化的容器
ConcurrentHashMap 怎么用才不踩坑？
它是并发 Map 的事实标准，但“线程安全”不等于“所有操作都原子”，尤其涉及复合逻辑时。
当用户要求为 Java 代码添加注释、修改注释、审查注释、整理注释格式，或要求按照代码注释规范处理 Java 文件时，使用本技能。本技能用于统一生成和维护 Java 类注释模板、按 Git 对比 release 判断版本号、补充每行代码上方中文块注释、调整注释空行规则，并保持 Java 文件 UTF-8 无 BOM 编码。典型触发场景包括：补充类注释、更新 @version、检查 @author 来源、整理行尾注释、把注释放到代码上一行、检查注释是否符合规范、构建前检查 Java 注释风格。
-
putIfAbsent(key, value)是原子的，适合实现单例缓存或防重复注册；而if (!map.containsKey(k)) map.put(k, v)不是原子的，必须用synchronized包裹或换computeIfAbsent() -
forEach()、keySet().iterator()返回的是弱一致性迭代器：遍历时其他线程的修改可能不可见，但绝不会抛ConcurrentModificationException—— 这是故意设计，不是 bug - JDK8+ 内部已无
Segment，锁粒度降到单个桶（Node），所以高并发下性能比 JDK7 更稳；但别对整个 map 加synchronized(map)，纯属画蛇添足
ConcurrentHashMap<String, Integer> counter = new ConcurrentHashMap<>();
counter.computeIfAbsent("req_count", k -> 0);
counter.compute("req_count", (k, v) -> v == null ? 1 : v + 1); // 安全自增
CopyOnWriteArrayList 什么时候该用、什么时候不该用？
它适合“读极多、写极少”的场景，比如监听器列表、配置白名单、告警规则集——但千万别把它当普通 ArrayList 随便塞日志。
立即学习“Java免费学习笔记（深入）”；
- 每次
add()、remove()都会复制整个底层数组，写操作成本是 O(n)，内存占用翻倍；10 万元素的列表删一个，就得新建一个 10 万长度的新数组 - 迭代绝对安全：
for (String s : list)期间其他线程增删不影响当前遍历，也不会抛异常——这是它唯一不可替代的优势 - 不支持
listIterator()的双向遍历，也不支持在迭代中调用list.remove()（那是 fail-fast 的老套路）
真正难的从来不是“哪个容器能用”，而是判断业务是否真需要并发容器：如果只是单线程处理批量数据，用 HashMap 更快；如果写操作频繁且要求强一致性（比如银行账户余额），ConcurrentHashMap 的弱一致性反而可能引入逻辑漏洞——这时候该考虑加锁或用 StampedLock 等更精细的控制。
