ConcurrentHashMap是高并发Map首选，采用CAS+synchronized锁单个节点，读无锁、写局部锁，键值不可为null，支持原子操作；CopyOnWriteArrayList适用于读多写少且需遍历安全的场景；ConcurrentLinkedQueue是无锁高性能队列，适合非阻塞生产者-消费者模型；Collections.synchronizedXxx和Vector/Hashtable因性能差、易误用而不推荐。
ConcurrentHashMap 是高并发 Map 的事实标准
绝大多数场景下，ConcurrentHashMap 应该是你替换 HashMap 的第一选择。它不是靠“整个 Map 加锁”来实现线程安全，JDK 8+ 后改用 CAS + synchronized 锁单个链表头或红黑树根节点，写操作冲突时才锁局部，读操作完全无锁。
- 键和值都不能为
null（这点和HashMap不同，避免歧义） - 迭代器是「弱一致性」：遍历时不会抛
ConcurrentModificationException，但可能看不到某些刚写入的元素，也可能看到已删除的残留 —— 这是设计取舍，不是 bug - 原子方法直接可用：
putIfAbsent()、computeIfAbsent()、merge()，无需额外同步 - 别用
containsKey() + get()组合判断再取值 —— 这不是原子操作，中间可能被其他线程修改；应改用computeIfAbsent()
CopyOnWriteArrayList 适合读多写少且需遍历安全的列表
当你需要在遍历过程中允许其他线程增删元素（比如事件监听器列表），又不想手动加锁，CopyOnWriteArrayList 就是为此而生。
- 每次
add()、remove()、set()都会复制整个底层数组，写开销大，不适合高频修改 - 读操作极快且无锁，
get()和size()都是 O(1) - 迭代器基于创建时的数组快照，遍历时哪怕其他线程已修改集合，也不会影响当前遍历结果，也不会抛异常
- 不适用于实时性要求高的写后即读场景 —— 新增元素对正在遍历的线程不可见
ConcurrentLinkedQueue 是无锁高性能队列的首选
如果你在做生产者-消费者模型，且不需要阻塞语义（比如不希望线程挂起等待），ConcurrentLinkedQueue 比 LinkedBlockingQueue 更轻量、更高效。
- 基于 CAS 实现，完全无锁，吞吐量高，适合大量短任务投递
- 非阻塞：
offer()和poll()都立即返回，失败也不抛异常（返回null或false） - 不支持
iterator.remove()，遍历时调用remove()可能导致未定义行为 - 注意：它不保证强一致性 —— 多线程同时
size()可能返回近似值（因为内部计数也是 CAS 更新，非原子快照）
别碰 Collections.synchronizedXxx，除非你清楚代价
Collections.synchronizedList(new ArrayList()) 看起来简单，但实际是个“半吊子安全”方案，容易误用出错。
- 单个方法如
add()、get()是线程安全的，但组合操作（比如先contains()再add()）仍需手动同步 - 最常踩的坑是遍历：
for (x : list)本质是隐式调用iterator()，而这个迭代器本身**不加锁**，必须显式synchronized(list) { ... }包裹整段循环 - 性能差：所有操作都锁整个对象，高并发下严重串行化，远不如
ConcurrentHashMap或CopyOnWriteArrayList - Vector / Hashtable 已被官方标记为遗留类，明确不推荐新代码使用
真正难的不是选哪个类，而是识别「读多写少」「需遍历中修改」「要阻塞等待」这些隐含条件。同一个业务里，监听器列表用 CopyOnWriteArrayList，计数统计用 ConcurrentHashMap，任务分发用 ConcurrentLinkedQueue，才是常态 —— 别指望一个容器通吃所有场景。
