ConcurrentHashMap 更适合高并发场景，因其采用分段锁（JDK 7）或 CAS + synchronized（JDK 8+），仅锁定修改的桶且读操作无锁；而 Hashtable 所有方法用 synchronized 修饰，竞争全局锁。
ConcurrentHashMap 为什么比 Hashtable 更适合高并发场景
因为 ConcurrentHashMap 不是简单地给整个表加锁，而是采用分段锁（JDK 7）或更轻量的 CAS + synchronized（JDK 8+）策略，只锁定发生修改的桶（bucket），读操作完全无锁。而 Hashtable 所有方法都用 synchronized 修饰，意味着每次 get() 或 put() 都要竞争同一把全局锁。
实操建议：
- 如果项目用 JDK 8+，
ConcurrentHashMap是默认首选；它支持computeIfAbsent()、merge()等原子操作，避免手动同步 - 不要用
ConcurrentHashMap的size()做精确计数判断——它返回的是估算值，多线程下可能不一致；需要精确大小时改用mappingCount() -
ConcurrentHashMap不允许null作为 key 或 value，否则抛NullPointerException；而HashMap允许一个nullkey
CopyOnWriteArrayList 在什么场景下真正有用
它适用于「读多写少」且遍历中可能被修改的场景，比如事件监听器列表、配置白名单缓存。每次写操作（add()、remove()）都会复制整个底层数组，所以写开销大，但迭代器永不抛 ConcurrentModificationException，也不需要额外同步。
常见误用现象：
立即学习“Java免费学习笔记（深入）”；
- 在 for-each 循环里调用
remove()—— 实际删的是旧副本，当前迭代器仍指向原数组，逻辑出错 - 把它当普通
ArrayList用在高频增删场景，CPU 和内存压力陡增 - 期望它保证「实时一致性」：写入后，正在遍历的旧迭代器看不到新元素，这是设计使然，不是 bug
使用 Collections.synchronizedList() 后为什么还会出现 ConcurrentModificationException
因为 Collections.synchronizedList(new ArrayList()) 只保证单个方法调用是线程安全的，不保证复合操作的原子性。例如 if (list.isEmpty()) list.add(x) 中，isEmpty() 和 add() 之间可能被其他线程插入元素，导致逻辑错误；更严重的是，迭代时若没手动同步，仍会触发 ConcurrentModificationException。
当用户要求为 Java 代码添加注释、修改注释、审查注释、整理注释格式，或要求按照代码注释规范处理 Java 文件时，使用本技能。本技能用于统一生成和维护 Java 类注释模板、按 Git 对比 release 判断版本号、补充每行代码上方中文块注释、调整注释空行规则，并保持 Java 文件 UTF-8 无 BOM 编码。典型触发场景包括：补充类注释、更新 @version、检查 @author 来源、整理行尾注释、把注释放到代码上一行、检查注释是否符合规范、构建前检查 Java 注释风格。
正确写法必须显式加锁：
List<String> list = Collections.synchronizedList(new ArrayList<>());
// 迭代必须手动同步
synchronized (list) {
Iterator<String> it = list.iterator();
while (it.hasNext()) {
System.out.println(it.next());
}
}
关键点：
-
synchronizedList包装类只是“语法糖”，底层仍依赖用户控制临界区 - 它无法防止迭代过程中的结构性修改（除非你始终用同步块包裹整个遍历）
- 相比
CopyOnWriteArrayList，它更适合写操作较少、但需要强一致性读写的场景
BlockingQueue 如何配合线程池实现生产者-消费者解耦
典型组合是 ThreadPoolExecutor + ArrayBlockingQueue 或 LinkedBlockingQueue。线程池的 workQueue 参数就是用来接住提交但暂未执行的任务，本质就是一个阻塞队列。
参数差异影响明显：
-
ArrayBlockingQueue是有界队列，容量固定，能防止内存溢出，但任务提交超限时会触发线程池的拒绝策略（如AbortPolicy抛RejectedExecutionException） -
LinkedBlockingQueue默认无界（Integer.MAX_VALUE），看似“不会满”，但实际可能导致 OOM；设为有界更可控 - 别直接用
PriorityBlockingQueue当线程池队列——它不保证公平性，且任务执行顺序与优先级不总一致
容易忽略的一点：线程池的 corePoolSize 和队列容量共同决定资源水位。例如 corePoolSize=2、队列容量=10，意味着前 12 个任务不会创建新线程；第 13 个才可能触发扩容（取决于 maxPoolSize）。这个组合逻辑常被低估。
