线程池隔离本身不是熔断器，但能为熔断和降级提供关键支撑：通过资源隔离避免故障扩散，为熔断策略争取判断窗口和执行缓冲；它将下游服务调用限定在独立线程池中，防止其耗尽全局线程资源，从而保障其他业务正常运行。
在微服务架构中，线程池隔离本身不是熔断器，但它能为降级和熔断提供关键支撑——通过资源隔离避免故障扩散，为熔断策略争取判断窗口和执行缓冲。
线程池隔离：为熔断争取“呼吸空间”
当某个下游服务（如用户中心）响应变慢或超时，若所有请求共用同一 Tomcat 线程池，会快速耗尽线程，导致整个服务不可用。线程池隔离把调用该服务的请求限定在独立线程池中，即使它卡住或失败，也不会影响其他业务（如订单、支付）的线程资源。
注意：线程池大小需合理——太小易拒绝正常请求，太大失去隔离意义。建议按下游服务 SLA（如 99% 响应
配合熔断器实现自动降级（以 Resilience4j 为例）
线程池隔离解决“不拖垮自己”，熔断器解决“不再反复尝试”。Resilience4j 的 CircuitBreaker 可监听线程池执行结果（成功/失败/超时/拒绝），自动切换状态：
立即学习“Java免费学习笔记（深入）”；
- 半开状态下，允许少量请求试探下游是否恢复
- 失败率超阈值（如 50%）或超时过多，自动跳闸，后续请求直接走降级逻辑
- 降级逻辑可返回缓存数据、默认值或空对象，避免抛异常中断主流程
关键点：熔断器要包装在线程池提交之后，而非替代线程池。例如用 executorService.submit(() -> circuitBreaker.executeSupplier(() -> callRemote()))。
拒绝与超时必须明确区分
线程池满时的 RejectedExecutionException 和远程调用超时（如 Feign timeout）含义不同，但都应触发降级：
- 拒绝 = 本地资源已满，说明下游持续不可用或流量突增，适合立即触发熔断
- 超时 = 下游响应慢，可能只是暂时抖动，可计入失败率，但不立即熔断
在 Resilience4j 中，可通过 recordFailurePredicate 分别配置两种异常的记录策略，让熔断更精准。
避免常见陷阱
线程池隔离不是银弹，容易踩坑：
- 不监控线程池使用率、队列堆积、拒绝数，就等于“装了保险丝却不看熔断指示灯”
- 未设置合理的拒绝策略（如
AbortPolicy默认抛异常），可能让上层误判为业务异常 - 忘记清理线程局部变量（ThreadLocal），在复用线程中引发脏数据或内存泄漏
- 将同步 RPC 调用直接丢进线程池，却没处理上下文传递（如 TraceId、认证信息），导致链路追踪断裂或权限校验失败
建议搭配 Micrometer 暴露线程池指标（active、queued、rejected），并在 Grafana 中建立告警。
