落地Java多线程规范关键在于将“易错自由”转为“安全约束”：统一显式声明带业务前缀的线程池（@Bean+有界队列+自定义ThreadFactory+拒绝策略）、按场景选锁（synchronized用于简单临界区，ReentrantLock仅需高级特性时使用且必finally unlock）、ThreadLocal必须配对remove防内存泄漏，并强化监控、trace透传与异常兜底。
在团队中落地 Java 多线程并发编程规范，关键不是堆砌技术术语，而是让规则可感知、可检查、可执行。核心是把“容易出错的自由”变成“安全路径优先的约束”，同时兼顾开发效率与线上稳定性。
统一建模：线程池必须显式声明 + 业务前缀
禁止直接 new ThreadPoolExecutor 或使用 Executors 的默认工厂方法（如 newFixedThreadPool、newCachedThreadPool）。这些方式隐藏了无界队列、拒绝策略缺失等致命风险。
- 所有线程池必须通过 @Bean 显式构造，参数完整：指定 corePoolSize / maxPoolSize / keepAliveTime / 有界队列（如 ArrayBlockingQueue(200)）/ 自定义 ThreadFactory（带业务前缀和序号，如 "order-notify-1"）/ 明确拒绝策略（推荐 CallerRunsPolicy 或自定义日志+降级）
- 变量命名强制带业务语义，如 payAsyncExecutor、logBatchWriter、smsRetryScheduler；禁用 executor、threadPool 等泛化名称
- 配合 @PreDestroy 注入 shutdown()，避免应用重启时线程残留导致内存泄漏或任务静默丢失
同步控制：按场景选锁，不盲目替换
synchronized 和 ReentrantLock 不是新旧替代关系，而是语义分工。团队需明确边界：
- 简单临界区保护（如缓存更新、计数器累加、状态标记）—— 优先用 synchronized：JVM 优化成熟、无手动 unlock 风险、代码简洁
- 需要超时获取、可中断等待、公平调度、或多个独立条件变量（如生产者/消费者解耦）—— 才启用 ReentrantLock，并且必须在 finally 块中 unlock()
- 禁止在 synchronized 块内调用外部服务（HTTP、RPC、DB 查询），应提前释放锁或改用异步回调
ThreadLocal 必须配套 remove()，尤其在线程复用场景
线程池中线程长期存活，ThreadLocal 若不清理，value 会随线程生命周期滞留，造成内存泄漏（key 虽弱引用但 value 是强引用）。
- 所有 ThreadLocal 变量必须配对使用：set() 后，在逻辑结束点（如 filter.doFilter() 结尾、@Async 方法返回前、Runnable.run() 末尾）调用 remove()
- 推荐封装工具类，如 ThreadLocalUtils.setAndRemove(key, value, () -> doWork())，自动保障 remove
- 在 Spring Web 环境中，建议结合 RequestContextHolder 或自定义 Filter 统一管理请求级 ThreadLocal 生命周期
协作与可观测：从“能跑”走向“可查、可控”
多线程问题难复现、难定位，规范要前置埋点和兜底能力：
- 每个线程池暴露监控指标：activeCount、queueSize、completedTaskCount、rejectedExecutionCount（接入 Prometheus + Grafana）
- 异步任务必须带 traceId 透传，禁止丢失上下文；使用 MDC 或 TransmittableThreadLocal 保证日志链路完整
- 所有 @Async 方法、线程池 submit 的 Runnable/Callable，必须包裹 try-catch，记录异常并触发告警，避免静默失败
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
