ConcurrentHashMap 是高并发读写场景的默认首选，分段锁或CAS+synchronized实现高吞吐，读无锁、写低冲突；误用get()+put()会导致更新丢失，应使用computeIfAbsent()等原子方法。
ConcurrentHashMap 适合绝大多数高并发读写场景
除非明确需要有序遍历或强一致性，ConcurrentHashMap 是 Java 并发集合中最稳妥的默认选择。它把哈希表分段加锁（JDK 8+ 改为 CAS + synchronized 细粒度锁），读操作完全无锁，写操作冲突概率低，吞吐量远高于 Hashtable 或 Collections.synchronizedMap()。
常见误用：用 ConcurrentHashMap 做计数器时直接调用 get() + put()，这会丢失更新。应改用 computeIfAbsent()、merge() 或 putIfAbsent() 等原子方法。
- 高频写入 + 低频遍历 → 优先选
ConcurrentHashMap - 需要 key 有序？改用
ConcurrentSkipListMap，但注意它不保证插入顺序，只按 key 自然序 - 如果只是偶尔写、大量读，且对弱一致性可接受，
ConcurrentHashMap的迭代器是弱一致的（不抛ConcurrentModificationException，但可能看不到最新写入）
BlockingQueue 类型要按生产消费模型匹配
选错 BlockingQueue 实现会导致线程频繁阻塞、虚假唤醒或内存暴涨。核心看三点：是否需要容量限制、是否要求公平性、是否需响应中断。
ArrayBlockingQueue queue = new ArrayBlockingQueue<>(1024, true); // 有界 + 公平
-
ArrayBlockingQueue：固定大小，构造时必须指定容量；公平模式下线程按等待顺序获取锁，但吞吐略低 -
LinkedBlockingQueue：默认无界（实际是Integer.MAX_VALUE），容易掩盖背压问题，导致 OOM；显式传入容量才真正有界 -
SynchronousQueue：不存储元素，每个put()必须立刻配对take()，适合手递手传递任务，不适合缓冲
CopyOnWriteArrayList 不适合写多场景
CopyOnWriteArrayList 的“写时复制”机制让它在读多写少、且遍历时不能出错的场景很香（比如监听器列表）。但每次写操作都要复制整个数组，时间 + 内存开销都大，写多时性能断崖式下跌。
立即学习“Java免费学习笔记（深入）”；
典型错误：把它当普通 ArrayList 用在循环中反复 add()，结果 CPU 和 GC 压力飙升。
- 只在读操作远多于写操作（比如 1000:1）、且写操作不频繁（秒级以下）时考虑
- 遍历中不需要同步，也不怕看到旧快照 —— 它的迭代器是快照式的，不会抛
ConcurrentModificationException - 永远不要用它存大对象（如 byte[]），复制成本太高
ThreadLocal 不是线程安全集合，别混用
ThreadLocal 常被误当作“线程安全的 Map”，但它本质是每个线程持有一份独立变量副本，不共享数据。它解决的是“避免参数层层传递”或“绑定线程上下文”，不是替代并发集合。
典型陷阱：用 ThreadLocal<map></map> 存共享缓存，以为线程安全就万事大吉，结果缓存无法跨线程复用，还可能因线程池复用导致内存泄漏（没调 remove()）。
- 需要每个线程隔离状态（如数据库连接、用户上下文）→ 用
ThreadLocal - 需要多个线程协作访问同一份数据 → 回到
ConcurrentHashMap、BlockingQueue等真正共享的并发结构 -
ThreadLocal的initialValue()只在首次get()时调用，不是每次 get 都新建
真正难的不是记住哪个类叫什么，而是判断“我的数据到底要不要跨线程共享”“读写比例大概多少”“能不能容忍弱一致性”。很多问题其实源于过早优化——先用 Collections.synchronizedXxx() 跑通逻辑，压测出瓶颈后再换并发集合，比一上来就套 ConcurrentHashMap 更可靠。
