核心变量任务需专属线程池实现硬隔离：核心组用固定大小池+拒绝策略，非核心组用弹性池；须命名规范、监控完备、调用链路显式指定池，且保障上下文透传与资源清理。

核心变量任务需要稳定、可预期的执行资源，不能被其他任务挤占或拖慢。直接用默认线程池（如 ForkJoinPool.commonPool()）或共用一个大线程池，容易导致关键任务因线程饥饿、I/O阻塞或队列积压而延迟甚至超时。分组隔离的本质，是为不同优先级、类型或业务域的任务分配专属线程池，实现资源硬隔离。

明确任务分组边界

先梳理系统中哪些任务属于“核心变量任务”——例如实时风控计算、订单状态同步、库存预扣减等，它们通常具备低延迟、高确定性、不可降级的特点。其余任务如日志上报、监控埋点、异步通知、批量导出等，可划为非核心组。分组不是按技术形态（如 Runnable/Callable），而是按业务语义和 SLA 要求划分。

• 核心组：独立线程池，固定大小（如 4–8），拒绝策略设为 AbortPolicy 或 CallerRunsPolicy，避免任务堆积掩盖问题
• 非核心组：可配置弹性线程池（如 newCachedThreadPool 或带界队列的 ThreadPoolExecutor），允许适度排队或拒绝
• 严禁跨组混用：不要把核心任务提交到非核心池，也不要让非核心任务通过 CompletableFuture.supplyAsync(task, pool) 误用核心池

构建带命名与监控能力的自定义线程池

线程池必须可识别、可追踪。使用 ThreadFactory 统一命名线程，便于日志排查和 JVM 线程 dump 分析；同时集成基础监控（如活跃线程数、队列长度、拒绝次数），不依赖外部框架也能快速感知异常。

• 线程名格式建议：core-calc-1、notify-batch-3，前缀体现分组，后缀为序号
• 推荐用 AtomicInteger 生成序号，避免并发重复
• 关键指标可通过 ThreadPoolExecutor 的 getActiveCount()、getQueue().size()、自定义 RejectedExecutionHandler 计数器暴露给 Prometheus 或日志

在调用链路中精准绑定分组池

隔离失效常发生在“看似隔离、实则穿透”的环节。比如 Spring 中的 @Async 默认走 SimpleAsyncTaskExecutor，或 CompletableFuture 未显式传入 Executor，都会退化到公共池。必须在每一处异步入口强制指定。

• CompletableFuture.supplyAsync(() -> doCoreCalc(), corePool)
• 手动提交：corePool.submit(() -> updateInventory(orderId))
• Web 层异步响应：用 DeferredResult + 自定义池处理耗时校验，而非阻塞 Tomcat 线程
• 避免隐式使用：禁用 parallelStream()，改用 ForkJoinPool 实例或直接提交至核心池

保障上下文传递与资源清理

核心任务常依赖请求上下文（如用户身份、traceId、事务对象）。线程切换后，ThreadLocal 会丢失，需主动透传。同时，数据库连接、HTTP 客户端等资源要确保在子线程中正确关闭或复用。

• 使用 RequestContextHolder.setRequestAttributes(..., true)（Spring）支持子线程继承
• 对 MDC（SLF4J）做手动拷贝：MDC.getCopyOfContextMap() + 子线程中 MDC.setContextMap()
• 核心池中的任务若开启新线程（如内部再起线程），仍需延续上下文，形成链式透传
• 任务结束前清理临时资源，防止内存泄漏或连接耗尽