线程池需按业务域隔离并显式传递上下文。必须为不同业务创建独立threadpoolexecutor实例，定制threadfactory命名，用contextawarerunnable封装透传mdc、用户信息等，差异化配置参数，并通过jstack、监控指标验证隔离效果。
线程池不能天然隔离业务，必须手动绑定上下文
Java原生ThreadPoolExecutor所有任务共享同一线程池资源，线程复用机制下，前一个任务留下的ThreadLocal、MDC日志上下文、数据库连接等极易污染后续任务。这不是配置问题，而是设计前提——线程池本身不感知业务语义。
常见错误现象包括：A业务的日志链路ID出现在B业务请求中；用户身份信息在异步任务里错乱；事务传播失效导致数据不一致。
- 必须为不同业务域创建独立的
ThreadPoolExecutor实例，而非共用一个线程池 - 避免使用
Executors.newFixedThreadPool()这类静态工厂方法，它们返回的线程池无法区分用途且难以监控 - 线程工厂（
ThreadFactory）需定制命名规则，例如"order-pool-%d"或"notify-pool-%d"，便于JVM线程dump时快速识别归属
如何安全传递业务上下文到线程池线程
不能依赖ThreadLocal跨线程自动继承——子线程不会复制父线程的ThreadLocal值。必须显式捕获并透传。
推荐做法是封装一层任务包装器，在提交前快照关键上下文：
立即学习“Java免费学习笔记（深入）”；
public class ContextAwareRunnable implements Runnable {
private final Runnable delegate;
private final Map<String, Object> contextMap;
public ContextAwareRunnable(Runnable r) {
this.delegate = r;
this.contextMap = copyCurrentContext(); // 如MDC.getCopy(), UserContextHolder.get()
}
@Override
public void run() {
try (var ignored = new ContextRestorer(contextMap)) {
delegate.run();
}
}
}
- 不要在
run()里直接调用MDC.setContextMap(...)后忘记清理，必须用try-with-resources或finally确保还原 - Spring项目可结合
RequestContextHolder，但注意其默认策略RequestAttributes.SCOPE_REQUEST在线程切换后不可用，需改用SCOPE_GLOBAL或自定义作用域 - 若使用
CompletableFuture，优先用supplyAsync(Supplier, Executor)而非无参重载，确保走自定义线程池
线程池参数要按业务特征差异化配置
订单通知和风控计算对延迟、吞吐、失败容忍度完全不同，共用一套corePoolSize/maxPoolSize/keepAliveTime必然出问题。
典型配置差异：
- 高实时性业务（如支付回调）：
corePoolSize == maxPoolSize，keepAliveTime = 0L，拒绝策略用AbortPolicy快速暴露瓶颈 - 批量离线任务（如报表生成）：
corePoolSize设小，maxPoolSize设大，搭配DelayedWorkQueue或自定义阻塞队列控制并发节奏 - IO密集型（如HTTP调用）：线程数建议设为
CPU核心数 × (1 + 平均等待时间/平均工作时间)，通常在8–32之间，避免过度创建线程引发上下文切换开销
监控和诊断线程池隔离是否生效
光靠代码逻辑不能确认隔离真实落地，必须通过运行时证据验证。
关键检查点：
- 用
jstack <pid></pid>观察线程名是否符合预期前缀，例如同时存在order-pool-1和notify-pool-3，说明实例已分离 - 在
beforeExecute和afterExecute钩子中打印上下文快照，验证每次执行前后的UserContext.get()是否始终与提交时一致 - 接入Micrometer或Prometheus，暴露各线程池的
activeCount、completedTaskCount、queueSize指标，避免某业务突发流量挤占其他业务线程资源
最容易被忽略的是线程工厂未透传上下文——即使线程池分开了，如果所有线程都叫pool-1-thread-1，出问题时根本无法定位到具体业务模块。命名规范不是锦上添花，是故障排查的底线。
