线程池隔离是降级的前提，因它为fallback提供独立执行环境：慢接口仅耗尽自身线程池，主业务线程仍可及时触发轻量fallback，避免共享池下全链路阻塞。
线程池隔离本身不直接“实现”降级，而是为降级提供可靠执行环境——它把故障关进独立线程池里，确保 fallback 方法能被及时、稳定地调用，而不是被卡死在阻塞线程中。
为什么线程池隔离是降级的前提
默认共享线程池下，一个慢接口（比如数据库超时）会耗尽所有线程，导致其他正常接口也无法响应，此时连执行降级逻辑的线程都没有。线程池隔离后，每个依赖服务拥有专属线程池，即使它持续超时或失败，也只是耗尽自己的池子，主业务线程仍可快速进入 fallback 流程，返回兜底数据或友好提示。
关键配置要点
- 按服务粒度划分线程池：不是按模块或功能，而是按具体依赖（如 orderService、paymentService、userCache），每个依赖对应独立线程池，避免交叉影响
- 合理设置核心数与队列容量：IO 密集型依赖（如 HTTP 调用）可设 corePoolSize = 10～20，maxPoolSize = 30，使用有界队列（如 ArrayBlockingQueue(100)），防止内存溢出
- 显式启用超时与拒绝策略：必须设置 command timeout（如 800ms），并搭配 CallerRunsPolicy 或自定义拒绝策略——当线程池满时，不丢任务也不抛异常，而是让调用方线程同步执行 fallback，实现平滑降级
与降级逻辑的配合方式
以 Hystrix 或 Resilience4j 为例，降级不是靠“自动触发”，而是由隔离机制保障其可执行性：
- 请求进入线程池后，若在 timeout 内未返回，则触发 fallback 方法（该方法运行在同一个隔离线程池内，不会阻塞主线程）
- fallback 方法应轻量：返回缓存值、静态默认值或空对象，禁止再调用外部服务或复杂计算
- 避免 fallback 嵌套调用其他可能失败的服务，否则可能再次引发阻塞或级联降级失效
信号量隔离的适用边界
信号量（Semaphore）适合内部低开销调用（如本地缓存读取、简单计算），它不创建新线程，仅计数并发数，开销小但无超时控制、不支持异步。一旦依赖响应慢，调用线程会被卡住，fallback 可能无法及时生效。因此需要可靠降级的外部依赖，必须选线程池隔离，不能用信号量替代。
