线程池隔离是解决核心链路被慢任务拖垮的根本手段，即通过物理拆分线程池，将毫秒级核心任务（如下单、支付）与耗时非核心任务（如AI推理、报表导出）彻底分离，各自配置独立的有界队列、合理线程数及匹配业务语义的拒绝策略，并辅以限流、超时和追踪等配套措施。
核心业务链路被慢查询拖垮，本质是资源争抢——快接口和慢任务共用同一组线程，一个慢 SQL 或外部调用卡住线程，其他请求只能排队等。解决的关键不是“让慢的更快”，而是“不让慢的干扰快的”。线程池隔离就是最直接、最有效的手段。
按业务域物理拆分线程池
把核心链路（下单、支付、查询）和非核心任务（报表导出、对账、AI 推理、日志上传）彻底分开，各自拥有独立的线程池。这不是可选项，而是生产环境的底线配置。
核心线程池：只跑订单创建、库存校验、用户信息查询等毫秒级任务
配置示例：core=10,max=30,queue=200, 拒绝策略用CallerRunsPolicy
目的是宁可让提交线程自己执行（变慢），也不丢任务、不抛异常、不阻塞容器主线程外部/慢任务线程池：专用于调用第三方接口、执行复杂 SQL、生成报表等
配置示例：core=5,max=15,queue=50, 拒绝策略可用AbortPolicy或自定义告警策略
即使它全满甚至失败，也不会影响核心池的一根线程
队列必须是有界的，且容量合理
立即学习“Java免费学习笔记（深入）”；
无界队列（如 LinkedBlockingQueue 默认构造）是隐形炸弹。慢任务一积压，队列无限膨胀，内存打满、GC 频繁、服务假死。一定要显式指定容量：
- 核心池队列建议 100–500，结合压测确定（例如 P99 延迟在 200ms 内能消化完的队列长度）
- 慢任务池队列建议 20–100，避免堆积过多待处理任务，靠限流或降级前置拦截
拒绝策略要匹配业务语义
-
DiscardPolicy：静默丢任务，绝不用于下单、支付等关键路径 -
AbortPolicy：抛RejectedExecutionException，适合慢任务池，配合上游重试或告警 -
CallerRunsPolicy：推荐用于核心池，让 Tomcat 线程同步执行任务——这会自然拉长响应时间，触发上游限流或用户端超时，反而是种安全的负反馈
配套措施不能少
光拆线程池不够，还得有兜底：
- 在入口层加限流（如 Sentinel QPS 控制），防止突发流量直接冲垮线程池
- 所有外部调用必须设超时（HTTP 连接+读取超时 ≤ 3s），避免一个卡死拖住全部线程
- 关键任务提交前记录唯一 trace ID 和状态（如 DB 中写
task_status='pending'），便于事后追踪是否丢失或卡住
不复杂但容易忽略。
