concurrenthashmap 更适合高并发场景，因其采用分段锁（jdk 7）或 cas + synchronized 锁单个 node（jdk 8+），读操作无锁、写操作细粒度加锁；而 hashtable 使用全局 synchronized 锁，吞吐量低。
ConcurrentHashMap 为什么比 Hashtable 更适合高并发场景
因为 ConcurrentHashMap 不是简单地给整个表加锁，而是把哈希表分段（JDK 8 后改用 CAS + synchronized 锁单个 Node），读操作完全无锁，写操作只锁必要节点。而 Hashtable 所有方法都用 synchronized 修饰，等同于一把全局锁，吞吐量在多线程下急剧下降。
实操建议：
- 除非遗留系统强制要求，否则永远优先选
ConcurrentHashMap而非Hashtable -
ConcurrentHashMap的size()和isEmpty()是弱一致性——可能反映的是某次快照状态，不适用于强校验逻辑 - 迭代时若其他线程修改了容器，不会抛
ConcurrentModificationException，但你看到的可能是过期数据
Vector 和 Collections.synchronizedList 的区别在哪
两者都提供线程安全的 List，但锁粒度不同：Vector 每个方法自带 synchronized，锁的是实例本身；Collections.synchronizedList(new ArrayList()) 则是对传入的 ArrayList 做装饰，所有方法也同步在同一个对象上。表面看没差别，但关键在于：它们都做不到复合操作原子化。
常见错误现象：
立即学习“Java免费学习笔记（深入）”；
-
if (list.size() > 0) list.get(0);—— 这段代码即使在Vector或同步 List 中仍可能抛IndexOutOfBoundsException，因为size()和get()是两次独立调用，中间可能被其他线程清空 - 想实现“不存在则添加”，不能靠
contains()+add()组合，必须自己用外部同步块包裹
正确做法示例：
synchronized (list) {
if (!list.contains(item)) {
list.add(item);
}
}
CopyOnWriteArrayList 适合什么场景，又为什么不能滥用
CopyOnWriteArrayList 在写操作（add、set、remove）时复制整个底层数组，读操作不加锁。它适合读远多于写的场景，比如监听器列表、配置白名单缓存。
但要注意：
- 每次写都触发数组复制，内存开销大，且随着集合变大，写延迟明显上升
- 迭代器基于创建时刻的快照，无法反映后续写入——所以它不适合需要实时感知变更的业务逻辑
- 不支持
Iterator.remove()，调用会抛UnsupportedOperationException
同步容器的迭代器都不是 fail-fast 的，这带来什么实际影响
像 ConcurrentHashMap、CopyOnWriteArrayList、ConcurrentLinkedQueue 的迭代器，都不会在检测到并发修改时抛 ConcurrentModificationException。这不是 bug，是设计取舍：以牺牲强一致性换并发性能。
这意味着：
- 你不能依赖迭代异常来发现并发 bug；反而要主动审查是否遗漏了必要的同步边界
- 如果业务逻辑要求“遍历中必须看到最新状态”，这些容器都不适用，得考虑
ReentrantLock+ 普通集合，或改用更高级的并发结构（如StampedLock读写锁） - 测试时容易漏掉竞态问题——单元测试跑一次没问题，压测时才暴露数据不一致
真正棘手的从来不是“怎么选容器”，而是“哪些操作必须串行化”——这个判断往往藏在业务语义里，而不是 API 文档里。
