任务隔离需按业务语义划分核心变量、非核心异步、框架内部三类任务，分别配置差异化线程池并显式绑定调用链路，辅以上下文透传与可观测性保障。
任务隔离与业务拆分不是配几个线程池就完事，关键在于让不同性质的任务互不干扰、资源可控、问题可溯。核心是按业务语义划分责任边界，再用线程池实现硬隔离。
按SLA和业务语义划分任务组
不能按技术形态（比如“用了Runnable”）分类，而要看任务在系统中的角色：
- 核心变量任务：实时风控计算、库存预扣减、订单状态同步——要求低延迟、强确定性、不可降级
- 非核心异步任务：日志上报、监控埋点、短信通知、批量导出——允许排队、延迟、甚至丢弃
- 框架内部任务：ShenYu网关里的Disruptor事件发布、监控插件上报、上游缓存刷新——必须与业务请求完全解耦
为每组配置专属线程池并差异化调优
共用一个大池子等于没隔离。各组线程池参数需匹配其任务特征：
- 核心组用固定大小线程池（如 core=4, max=4），拒绝策略设为 AbortPolicy 或 CallerRunsPolicy，防止队列堆积掩盖真实瓶颈
- 非核心组可用带界队列的弹性池（如 core=2, max=10, queue=100），避免突发流量拖垮整个系统
- 框架任务池（如 soul-disruptor、soul-log-disruptor）必须独立命名、独立监控，且线程数通常设为 CPU 核心数×2，避免抢占业务资源
在调用链路中显式绑定线程池
隔离失效往往发生在“隐式提交”环节：
立即学习“Java免费学习笔记（深入）”；
- 禁用
parallelStream()，改用ForkJoinPool.commonPool()显式传参，或直接提交到指定池 -
CompletableFuture.supplyAsync()必须传入 Executor，不能依赖无参重载 - @Async 注解需配合自定义
TaskExecutorBean，且每个业务场景应声明对应 Bean - Web 层耗时校验建议用
DeferredResult+ 自定义池，不阻塞 Tomcat 工作线程
保障上下文透传与可观测性
线程切换后 MDC、用户上下文、事务信息容易丢失，必须主动处理：
- 封装
ContextAwareRunnable，在 run 前拷贝当前上下文，结束后自动还原 - 线程名统一规范，如
core-risk-1、notify-sms-3，便于日志追踪和线程 dump 分析 - 暴露关键指标：活跃线程数、队列长度、拒绝次数，接入 Prometheus 或写入日志
- 拒绝策略中增加计数器，当拒绝率持续超过阈值时触发告警
