直接用一个线程池扛所有异步任务必然出问题，必须按业务语义（如sla、故障影响范围）和任务性质（runnable/callable）划分隔离线程池，核心变量组需保障低延迟与强一致。
直接用一个线程池扛所有异步任务，短期省事，长期必出问题。核心任务被日志上报拖慢、风控计算被批量导出挤占线程、订单状态同步因队列积压超时——这些都不是偶发故障，而是隔离缺失的必然结果。业务压力要拆，关键不是“多开几个池”，而是按业务语义划清边界、配准参数、管住调用入口。
按SLA和业务语义划分任务组
别按技术形态（Runnable/Callable）分，要按“这个任务崩了会不会导致交易失败”来判断。常见分组参考：
- 核心变量组：实时风控决策、库存预扣减、订单状态强一致同步——要求低延迟（
- 高吞吐非核心组：用户行为埋点、邮件短信通知、监控指标上报——允许排队、可丢弃、延迟容忍度高（秒级）
- 长耗时离线组：报表导出、数据清洗、文件归档——执行时间分钟级，需防阻塞，不参与实时链路
为每组配置差异化的线程池参数
共用一套corePoolSize/maxPoolSize是最大误区。不同任务负载特征差异巨大：
- 核心组用固定大小线程池（如 core=4, max=4），队列用SynchronousQueue，拒绝策略设为CallerRunsPolicy——宁可在主线程降级执行，也不让任务堆积掩盖问题
- 非核心组可用带界队列的弹性池（如 core=2, max=10, queue=50），避免无限创建线程耗尽资源；IO密集型任务可适当放大maxPoolSize
- 长耗时组建议用独立CachedThreadPool或自定义大空闲时间池（keepAliveTime设为5–10分钟），防止短连接频繁启停
强制绑定与上下文透传
隔离失效往往发生在“看似指定、实则退化”的环节：
- Spring @Async必须显式指定executor：
@Async("coreCalcExecutor")，禁用默认SimpleAsyncTaskExecutor - CompletableFuture一律用带Executor的重载：
supplyAsync(task, corePool)，绝不用无参版本 - Web层异步响应（如DeferredResult）需手动提交至对应池，不依赖容器线程
- MDC、RequestContextHolder等上下文必须封装透传：用ContextAwareRunnable包装任务，try-with-resources自动还原，避免跨任务污染
可观测性与命名规范
池子建了不等于隔离生效，得看得见、管得住：
- 线程名统一前缀+序号：
core-risk-1、notify-sms-3，便于jstack排查和日志追踪 - 暴露关键指标：活跃线程数、队列长度、拒绝次数，接入Prometheus或写入日志
- 禁止parallelStream()隐式使用ForkJoinPool.commonPool()，改用显式提交到业务池
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
