线程池隔离需按业务域物理拆分快慢任务、配置有界队列与匹配语义的拒绝策略，并辅以超时、限流和状态追踪等配套措施。
线程池隔离不是加个新线程池就完事，而是围绕“不互相干扰”这个目标，对业务流量做物理切分和资源划界。核心思路是：快任务和慢任务不能共用一套线程资源，否则一个慢 SQL 或外部超时，就能把整个服务拖垮。
按业务域拆分线程池
把系统任务明确归类，各自绑定专属线程池：
- 核心链路池：只跑下单、支付、实时库存校验、用户身份鉴权等毫秒级任务；不允许执行任何外部 HTTP 调用或复杂查询
- 异步/慢任务池：专用于报表导出、AI 推理、日志落盘、对账计算、第三方通知等耗时操作
- 定时任务池（可选）：独立承载 ScheduledTask，避免 cron 触发时抢占核心资源
队列必须有界，容量要合理
无界队列（如 new LinkedBlockingQueue()）是生产事故高发点。一旦下游变慢，任务持续堆积，内存暴涨、GC 频繁、服务假死。
- 核心池队列建议 100–500，结合压测 P99 延迟反推：比如平均响应 80ms，希望排队不超过 200ms，则队列长度 ≈ 200 / 80 × 并发数
- 慢任务池队列建议 20–100，靠前置限流（如 Sentinel）或降级兜底，不让大量待处理任务积压
拒绝策略要匹配业务语义
不同池子的“失败”含义完全不同，拒绝策略不能一刀切：
- 核心池推荐
CallerRunsPolicy：当队列满、线程达上限时，由 Tomcat 线程同步执行任务。这会让接口变慢，但不会丢单、不抛异常、不阻塞容器主线程，反而能自然触发上游限流或前端超时，是一种安全的负反馈 - 慢任务池可用
AbortPolicy：直接抛RejectedExecutionException，配合重试机制或告警，失败不影响主链路 - 避免在关键路径用
DiscardPolicy，静默丢弃下单请求等于资损
配套措施缺一不可
光靠线程池隔离不够，还得有防御纵深：
- 所有外部调用必须设超时（HTTP 连接 + 读取 ≤ 3s），禁用无超时的 OkHttp / Feign 默认配置
- 入口层加 QPS 限流（如 Sentinel Resource + Rule），防止突发流量直接打爆线程池
- 关键异步任务提交前写 DB 记录状态（如
task_status = 'pending'），便于事后核对是否丢失或卡住
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
