线程池隔离需从创建、上下文传递、参数配置、监控验证四层面同步落地：各业务域须独享命名ThreadPoolExecutor实例，封装ContextAwareRunnable透传还原上下文，按IO/CPU/GPU特征差异化配置参数，并通过日志、线程名、指标三维度验证隔离有效性。
线程池隔离不是加个线程池就完事，关键在于让不同业务真正“互不看见”。业务变量污染、上下文错乱、资源抢占这些现象，本质是共享线程导致的执行环境混杂。必须从线程池创建、上下文传递、参数配置、监控验证四个层面同步落地。
为每个业务域分配独立线程池实例
不能共用 Executors.newFixedThreadPool() 或单个全局线程池。订单、通知、风控、AI推理等核心业务模块，必须各自持有专属的 ThreadPoolExecutor 实例。
- 用
ConcurrentHashMap按业务标识（如"order-async"、"ai-inference-gpu"）管理线程池，避免硬编码泄漏 - 禁用静态工厂方法——它们返回的线程池无命名、无监控入口、无法差异化调参
- Dubbo 场景下，通过
@DubboService(executor = "xxxExecutor")绑定服务级线程池；Spring Boot 中可声明多个@Bean并注入对应Executor
显式透传并自动还原执行上下文
ThreadLocal 和 MDC 不会跨线程继承，父线程的用户ID、链路TraceID、事务上下文在子线程里默认为空或残留旧值。必须在任务提交前捕获，在执行前后自动还原。
- 封装
ContextAwareRunnable：构造时调用MDC.getCopy()、UserContextHolder.current()等快照当前上下文 - 执行时用
try-with-resources或finally还原，确保即使异常退出也不污染后续任务 - Spring 项目慎用
RequestContextHolder默认的SCOPE_REQUEST，应切换为SCOPE_GLOBAL或自定义作用域支持线程切换 - 使用
CompletableFuture时，始终指定自定义Executor，避免误入ForkJoinPool.commonPool()
按业务特征差异化配置线程池参数
同一套 corePoolSize/maxPoolSize/keepAliveTime 套所有业务，等于把快递车、消防车、救护车全塞进同一个车库调度。
- 订单通知类 IO 密集型任务：线程数可设为 CPU 核心数 × (1 + IO等待占比)，队列用
LinkedBlockingQueue防止突发堆积压垮内存 - 风控计算类 CPU 密集型任务：线程数建议
CPU核心数 + 1，拒绝策略选CallerRunsPolicy让调用方降速，避免雪崩 - GPU 推理任务：核心线程数 ≤ 单卡最大并发模型数（如 4），拒绝策略返回 HTTP 503 并附带排队深度，便于前端限流决策
- 所有线程工厂必须定制命名，如
new NamedThreadFactory("payment-callback-pool")，方便jstack快速定位线程归属
用监控和诊断手段验证隔离是否生效
没验证的隔离等于没做。重点观察三类信号：
- 日志层面：检查 A 业务日志中是否出现 B 业务的 TraceID 或用户ID；MDC 输出是否稳定不串行
-
线程层面：用
jstack -l查看线程名，确认各业务线程严格分布在对应命名池中，无交叉复用 -
指标层面：采集各线程池的
activeCount、queueSize、rejectedTaskCount，设置分组告警（如订单池拒绝率 > 0.1% 触发告警，通知池则容忍 1%）
