17370845950

Java并发编程质量关键在于规避共享状态、职责清晰和精准同步；ConcurrentHashMap优于手动锁HashMap；避免synchronized块中I/O；慎用ThreadLocal，优先框架上下文传递。

Java并发编程质量不取决于用了多少高级工具，而在于是否规避了共享状态、是否让线程职责清晰、是否在关键路径上做了必要同步且不多余。

用 ConcurrentHashMap 替代 HashMap + synchronized

手动加锁保护 HashMap 是常见但危险的做法：容易漏锁、死锁，且读操作也被阻塞。而 ConcurrentHashMap 的分段锁（JDK 8+ 改为 CAS + synchronized 细粒度节点锁）天然支持高并发读写。

• 写入场景：直接调用 put()、computeIfAbsent()，无需额外同步
• 遍历场景：迭代器弱一致性，不抛 ConcurrentModificationException，但可能看不到最新写入 —— 这是设计取舍，不是 bug
• 注意别误用 size()：它返回估算值；如需精确计数，改用 mappingCount()

避免在 synchronized 块里做 I/O 或远程调用

同步块本质是串行化临界区，一旦里面包含耗时操作（如数据库查询、HTTP 请求），会严重拖慢其他线程，甚至引发线程池饥饿。

• 正确做法：把 I/O 拆到同步块外，只在真正需要保护共享状态的地方加锁
• 示例：先查缓存（无锁），若 miss 再进入同步块检查并加载，加载完成后再异步刷新下游系统
• 警惕 synchronized(this)：暴露

  

  锁对象，外部可任意加锁干扰内部逻辑；优先用私有 final 锁对象，如 private final Object lock = new Object();

用 CompletableFuture 替代裸 Thread 或 ExecutorService.submit(Runnable)

手动管理线程生命周期和结果传递极易出错：忘记 join()、异常丢失、回调嵌套地狱、线程复用混乱。

• supplyAsync() + thenApply() 可自然链式编排，异常由 exceptionally() 或 handle() 捕获
• 默认使用 ForkJoinPool.commonPool()，但 IO 密集型任务建议显式传入专用线程池，如 Executors.newCachedThreadPool()
• 慎用 get()：会阻塞当前线程；优先用 thenAccept() 等非阻塞方式消费结果

别依赖 ThreadLocal 传参，尤其在线程池中

ThreadLocal 在线程复用场景下极易造成内存泄漏或上下文污染 —— 上一个请求设的值，下一个请求没清理就直接读到了。

• Web 应用中，务必在 Filter 或拦截器末尾调用 threadLocal.remove()，不能只靠 set(null)
• 如果只是想透传请求上下文（如 traceId），优先考虑框架能力：Spring 的 RequestContextHolder、SLF4J 的 MDC 已内置清理机制
• 自定义 ThreadLocal 时，应重写 initialValue() 而非构造时赋值，避免子线程继承父线程值

并发问题往往在压测或上线后才暴露，而修复成本远高于设计阶段的约束。最值得花时间的，不是学新 API，而是厘清哪些变量真需要共享、哪些状态本该属于单次请求生命周期。