线程池需按业务域严格隔离，采用“业务域-功能-角色”三段式命名，独占ThreadPoolExecutor实例，并通过ContextAware封装实现上下文快照与自动还原，辅以jstack、日志聚合及压测验证隔离有效性。
大厂级多业务线共存时，线程池不是“能跑就行”的工具，而是状态污染的高危通道。一个订单模块的MDC链路ID、用户上下文、事务绑定，若未隔离，极可能透传到风控或通知线程中，造成日志错乱、权限越界、事务回滚失败等隐蔽故障。根本解法不在加锁或注释，而在从线程创建源头就建立可识别、可归属、可清理的隔离契约。
线程工厂必须带业务域前缀与角色标识
统一用`业务域-功能-角色`三段式命名，例如：
- order-pool-notify-thread-7：订单域 + 通知功能 + 工作线程
- risk-pool-scan-worker-3：风控域 + 扫描任务 + 工作者线程
- report-pool-export-cpu-2：报表域 + 导出任务 + CPU密集型专用线程
禁用无意义数字编号（如“pool-1-thread-1”）或全局统一名字（如“biz-thread”）。命名要让运维在jstack、Arthas thread命令或监控大盘中一眼锁定归属模块，也为后续自动打标（如Prometheus线程维度标签）提供结构化基础。
每个业务线独占ThreadPoolExecutor实例
禁止跨业务复用同一ThreadPoolExecutor，哪怕参数一致。原因很直接：线程复用机制下，前序任务残留的ThreadLocal、MDC、RequestContextHolder、数据库连接绑定等，会在下个任务执行时被继承——而这个“下个任务”很可能属于另一个业务线。
- 订单服务不能和积分服务共用一个线程池；
- 实时风控计算与离线数据清洗必须物理隔离；
- 连健康检查探测任务也应使用独立小线程池，避免探针线程污染主业务上下文。
Spring Boot中建议通过@Bean声明+@Qualifier限定，配合@Profile或模块化条件加载，确保IOC容器里每个线程池实例有唯一且语义明确的bean name。
上下文透传必须显式快照+自动还原
ThreadLocal不跨线程继承，MDC不会自动复制，Spring的RequestContextHolder默认是request scope，在异步线程中为空。必须在提交任务前捕获关键上下文，并在线程入口处还原、退出时清理。
- 封装
ContextAwareRunnable或ContextAwareCallable，构造时调用MDC.getCopy()、UserContext.snapshot()、TransactionSynchronizationManager.getCurrentTransactionName()等； - run()方法内用try-finally或try-with-resources保证上下文还原，避免因异常跳过清理；
- 对
CompletableFuture，强制使用supplyAsync(supplier, executor)重载，拒绝无参版本； - 禁止在异步线程内手动
MDC.setContextMap()后不clear()，这是日志污染最常见源头。
监控与验证必须覆盖隔离有效性
命名和隔离不是写完就结束，得可观测、可验证：
- 通过
jstack -l <pid>定期抓取线程堆栈，搜索关键词如“notify”、“risk”，确认线程名与业务域严格对应； - 在日志采集端（如Logback + ELK）按
%X{traceId}与线程名联合聚合，检查是否存在跨业务traceId混入； - 压测时注入不同业务的模拟请求，观察各线程池的活跃线程数、队列积压、拒绝率是否彼此独立波动；
- 引入自定义
RejectedExecutionHandler，记录被拒任务的原始上下文（如URI、method、traceId），反向定位隔离缺口。
