ConcurrentHashMap 比 Hashtable 更快因其采用分段锁（JDK 7）或 CAS + synchronized（JDK 8+），写操作仅锁对应桶，读操作无锁；size() 高并发下不准且慢，应优先用 mappingCount()。
ConcurrentHashMap 为什么比 Hashtable 更快？
它用分段锁（JDK 7）或 CAS + synchronized（JDK 8+）代替了 Hashtable 的全局锁，写操作只锁住对应桶（bucket），读操作甚至完全无锁。实际用的时候，别把它当普通 HashMap 一样调用 size()——这个方法在高并发下要遍历所有 segment 或 counterCells，结果可能不准还慢；真要计数，优先用 mappingCount()，它返回的是 long 类型的近似值，更轻量。
- 如果你正在迁移老代码，把
Hashtable换成ConcurrentHashMap，注意put(null, v)和put(k, null)都会抛NullPointerException，而Hashtable只禁止 key 为 null -
computeIfAbsent()是线程安全的“查无则建”，适合缓存初始化场景，但传入的 mappingFunction 不应有副作用，否则重复执行风险高 - 迭代时用
keySet().forEach()比用传统 for-each 更安全，后者可能因结构修改触发ConcurrentModificationException（虽然概率低，但不是完全免疫）
ExecutorService.submit() 和 execute() 到底该选哪个？
submit() 返回 Future，能取结果、判状态、设超时；execute() 只是扔任务进队列，连异常都捕获不到——除非你显式在 Runnable 里 try-catch。线上服务里，只要任务有返回值、需要控制生命周期、或得知道它挂没挂，一律用 submit()。
-
submit(Runnable task)返回的Future调用get()会得到null，别误以为出错了 -
submit(Callable<t> task)</t>才真正承载返回值，异常也会包装进ExecutionException，记得 catch 住再处理 - 如果用了
execute()，线程池内部抛出未捕获异常时，会静默吞掉，只能靠Thread.setDefaultUncaughtExceptionHandler()补救，但这个 handler 对 ForkJoinPool 无效
CountDownLatch 和 CyclicBarrier 什么时候会互相替代不了？
CountDownLatch 是“一等多”：一个线程等 N 个其他线程完成；CyclicBarrier 是“多等多”：N 个线程彼此等待，齐头并进。前者不能重置，后者可以 reset()，所以做分批任务（比如每 100 条数据同步一次）只能用 CyclicBarrier。
-
CountDownLatch的await(long timeout, TimeUnit unit)返回 boolean，false 表示超时，但 latch 状态不变，后续还能 await —— 别当成“失效”直接丢弃 -
CyclicBarrier构造时传的Runnable在每次屏障触发时执行一次，且由最后一个到达的线程调用，别在里面做耗时操作，否则拖慢整组线程 - 如果某个线程在
await()时被中断，两个类都会抛InterruptedException并重置状态：CountDownLatch不可恢复，CyclicBarrier则进入 broken 状态，后续所有 await 都立即失败
CompletableFuture 异步链里异常怎么不漏掉？
它默认不会把异常传播到主线程，join() 或 get() 才会暴露。最常见错误是写了 thenApply() 后没接 exceptionally() 或 handle()，导致上游异常被吞，日志里只看到 “null result” 或线程静默退出。
立即学习“Java免费学习笔记（深入）”；
-
thenApply()和thenAccept()这类“后继函数”遇到上游异常会跳过执行，必须用exceptionally(Function<Throwable, T>)捕获，或者统一用handle(BiFunction<T, Throwable, R>) -
whenComplete()一定执行，无论成功失败，但它不改变结果值，适合打日志或清理资源；handle()则可以返回新值，适合兜底转换 - 多个
CompletableFuture用allOf()组合时，它本身不抛异常，得手动检查每个 future 的isCompletedExceptionally()，或者用allOf(...).thenCompose(v -> ...)套一层再处理
并发工具包的坑大多藏在“看似和单线程一样用”的地方：比如 size()、iterator()、异常传播路径、以及重入/重置行为。越想省事直接套用旧习惯，越容易在线上卡住半天才定位到是某个并发容器的语义理解错了。
