Vector和Hashtable因全局synchronized锁导致高并发性能差；ConcurrentHashMap（JDK8+）采用分桶锁+CAS提升吞吐；CopyOnWriteArrayList仅适用于读多写少场景；BlockingQueue选型需权衡容量、锁机制与背压策略。
Vector 和 Hashtable 为什么慢得明显
它们靠 synchronized 锁整个对象，每次 add()、get()、put() 都要抢同一把锁。高并发下线程排队，CPU 空转，吞吐直接掉一半以上。
常见错误现象：Vector.size() + Vector.get(i) 循环遍历时，看似安全，实则两次调用之间可能被其他线程修改，导致 ArrayIndexOutOfBoundsException —— 因为 size() 和 get() 是两个独立同步块，不构成原子操作。
- 不要用
Vector存高频写入的缓存列表（比如实时订单队列） -
Hashtable不支持null键或值，而HashMap支持；但别为了这点便利退回到Hashtable - 如果只是单线程场景，用
ArrayList/HashMap就够了，没必要上同步容器
ConcurrentHashMap 在 JDK 8+ 怎么避免锁全局
JDK 8 把分段锁（Segment）彻底干掉了，改用 Node 数组 + synchronized 锁单个桶（bin），再配合 CAS 操作。读操作完全无锁，写冲突只发生在哈希碰撞的同一个桶里。
性能影响很实际：16 线程并发 put，ConcurrentHashMap 吞吐通常是 Hashtable 的 5–10 倍；扩容时也支持多线程协助迁移，不像 HashMap 扩容是全表阻塞。
-
computeIfAbsent()是线程安全的，适合做懒加载缓存，但注意 lambda 里别放耗时逻辑，否则卡住整个桶 - 别用
keySet().iterator()做“一边遍历一边 remove”——它不保证强一致性，可能漏删或抛ConcurrentModificationException -
size()返回的是估算值，高并发下可能不准；真要精确计数，用mappingCount()
CopyOnWriteArrayList 适合什么场景，又为什么不敢乱用
写操作触发数组复制，读完全无锁。所以它只适合「读多写少」且写操作不频繁的场景，比如监听器列表、配置白名单。
分析 Java Spring Boot 后端 Controller 代码，自动生成 Markdown 格式的接口文档。当用户说“生成 Java 接口文档”、“生成 API 文档”、“从 Spring 代码生成文档”时触发。
容易踩的坑在于内存和延迟：每次 add() 都新建数组并拷贝全部元素，10 万条数据写一次，就要分配 10 万对象引用 + 复制开销；更糟的是，写操作完成后，其他线程读到的仍是旧副本，存在明显可见性延迟。
- 千万别在循环里反复调用
add()构建大集合，OOM 风险极高 - 它不支持
ListIterator的set()和remove()，因为迭代器基于快照，改了也没用 -
get()很快，但indexOf()或contains()是 O(n)，且查的是快照时刻的数据，不是最新状态
BlockingQueue 实现类选哪个，取决于你等不等、怎么等
ArrayBlockingQueue 是定长数组 + 一把 ReentrantLock，适合容量可控、对吞吐稳定性要求高的场景（如线程池任务队列）；LinkedBlockingQueue 默认无界，用两把锁（takeLock / putLock），读写可并行，但无界可能导致内存撑爆。
最常被忽略的是拒绝策略：ThreadPoolExecutor 用 ArrayBlockingQueue 时，队列满会触发 RejectedExecutionHandler；而用无界 LinkedBlockingQueue，等于把背压转移到内存，OOM 比拒绝更难排查。
- 生产者不能无限快 push，消费者必须跟得上节奏，否则不管哪种
BlockingQueue都会积压 -
offer(e, timeout, unit)比put(e)更可控，超时返回 false 可做降级处理 -
PriorityBlockingQueue不保证公平性，相同优先级元素可能乱序，别依赖插入顺序
真正决定性能代差的，从来不是“用了没用并发容器”，而是你有没有看清读写比例、是否接受延迟一致性、以及愿不愿意为写操作的代价买单。这些点一旦错配，换再新的 JUC 类也救不回来。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
