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()、异常丢失、回调嵌套地狱、线程复用混乱。
立即学习“Java免费学习笔记（深入）”；
-
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，而是厘清哪些变量真需要共享、哪些状态本该属于单次请求生命周期。
