Java并发工具包核心类解析

本文深入剖析Java并发工具包的核心类使用要点与常见陷阱，揭示ConcurrentHashMap为何比Hashtable更高效（分段锁/CAS+synchronized机制、避免全局锁）、强调size()的高并发缺陷及mappingCount()的正确替代方案，并详解computeIfAbsent()的线程安全边界、ExecutorService中submit()与execute()的关键差异、CountDownLatch与CyclicBarrier的本质适用场景、CompletableFuture异常传播易被忽略的致命细节，以及迭代、重置、中断处理等高频踩坑点——所有内容直击开发者在迁移老代码或设计高并发系统时最易误解、最难排查的“伪安全”用法，帮你避开那些看似正常实则埋雷的并发陷阱。

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 task) 才真正承载返回值，异常也会包装进 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” 或线程静默退出。

• thenApply() 和 thenAccept() 这类“后继函数”遇到上游异常会跳过执行，必须用 exceptionally(Function) 捕获，或者统一用 handle(BiFunction)
• whenComplete() 一定执行，无论成功失败，但它不改变结果值，适合打日志或清理资源；handle() 则可以返回新值，适合兜底转换
• 多个 CompletableFuture 用 allOf() 组合时，它本身不抛异常，得手动检查每个 future 的 isCompletedExceptionally()，或者用 allOf(...).thenCompose(v -> ...) 套一层再处理

并发工具包的坑大多藏在“看似和单线程一样用”的地方：比如 size()、iterator()、异常传播路径、以及重入/重置行为。越想省事直接套用旧习惯，越容易在线上卡住半天才定位到是某个并发容器的语义理解错了。

理论要掌握，实操不能落！以上关于《Java并发工具包核心类解析》的详细介绍，大家都掌握了吧！如果想要继续提升自己的能力，那么就来关注golang学习网公众号吧！