单机多线程池隔离架构的核心是切断资源、上下文、调度三类耦合：资源硬隔离需按业务域专属建池并差异化配置；上下文透传须封装contextawarerunnable并禁用默认requestcontextholder；调用链路绑定要求所有异步操作显式指定线程池，禁用parallelstream()等隐式池调用；可观测性需统一命名、暴露指标、增强日志并定期巡检。
单机多线程池隔离架构的核心目标，是让非核心业务“出问题不传染”，关键不在加几个池，而在切断三类耦合：资源耦合、上下文耦合、调度耦合。
资源硬隔离：每个业务域独占线程与队列
不能共用一个 ThreadPoolExecutor 实例，更不能依赖 Executors 工厂方法（无命名、无监控入口、参数无法差异化）。必须为不同业务域创建专属线程池：
- 订单风控、库存预扣减等核心任务 → 固定大小池（如 core=4, max=4），队列用 SynchronousQueue，拒绝策略设为 AbortPolicy 或 CallerRunsPolicy，宁可降级也不堆积
- 短信通知、日志上报、报表导出等非核心任务 → 弹性池（core=2, max=10），队列用有界 LinkedBlockingQueue（如 capacity=50），拒绝策略返回友好提示并记录告警
- AI推理等 GPU 任务 → 核心线程数 ≤ 单卡最大并发数（如 4），拒绝时直接返回 HTTP 503 + 当前排队深度，便于前端主动限流
上下文透传：避免 ThreadLocal 和 MDC 在子线程失效
父线程的用户 ID、TraceID、事务上下文默认不会继承到子线程。若不处理，非核心任务执行中可能污染核心链路的上下文，或导致日志/监控错乱：
- 封装 ContextAwareRunnable：构造时捕获 MDC.getCopy()、UserContextHolder.current() 等快照；run() 中用 try-with-resources 或 finally 还原，确保异常也不残留
- Spring 项目禁用 RequestContextHolder 默认的 SCOPE_REQUEST；改用 SCOPE_GLOBAL 或自定义作用域支持跨线程传递
- CompletableFuture 必须显式指定 Executor，禁止使用 supplyAsync(Runnable) 无参重载（会掉进 ForkJoinPool.commonPool）
调用链路绑定：从入口杜绝误用和穿透
隔离失效往往发生在“看似用了池、实则没走池”的环节。必须在每一处异步发起点强制指定归属线程池：
- @Async 注解必须配合 @EnableAsync + 自定义配置，且每个方法标注 @Async("notifyPool")，禁用默认 SimpleAsyncTaskExecutor
- Web 层耗时校验（如风控）用 DeferredResult + 核心池处理，不阻塞 Tomcat 线程
- 禁用 parallelStream() —— 它默认走 commonPool，应改用 ForkJoinPool 实例或直接 submit 到对应业务池
- 通过 ConcurrentHashMap
按 key（如 "risk-calc", "sms-send"）管理池实例，避免硬编码泄漏
可观测与兜底：让隔离真正“看得见、控得住”
没有监控的隔离等于裸奔。每个线程池需自带基础可观测能力：
- 线程工厂统一命名：如 new NamedThreadFactory("risk-core-")，jstack 一眼识别归属
- 暴露关键指标：活跃线程数、队列长度、拒绝次数，可通过 JMX 或 Prometheus 直接采集
- 日志打点增强：在任务 run() 前后打印线程名 + 业务标识，排查时快速定位是否跑错池
- 定期巡检：检查是否存在未注册到池管理器的匿名线程池，或被框架自动创建的默认池
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
