hystrix线程隔离与信号量隔离本质是两种资源控制机制：线程隔离通过独立线程池实现超时控制、异步调用和彻底上下文隔离，适用于不可信、慢速、网络依赖；信号量隔离基于计数器限制并发，零线程开销、支持动态调整，但不支持超时和异步，仅适用于可信、极快的本地调用。
Hystrix 的线程隔离和信号量隔离本质是两种资源控制机制，选哪种不看“高级感”，而看实际调用场景是否匹配其能力边界。
线程隔离：适合不可信、慢、需超时控制的依赖
它为每个 HystrixCommand 分配独立线程池（比如 Dubbo 接口、HTTP 外部服务），请求线程（如 Tomcat 线程）提交任务后立即返回，真正执行在 Hystrix 自己的线程中。
- 支持设置超时时间（executionTimeoutInMilliseconds），超时直接中断并 fallback，不卡主线程
- 天然支持异步调用，可配合
queue()或observe()实现非阻塞 - 能防止下游慢导致上游线程池耗尽（比如 Tomcat 线程被占满），避免级联雪崩
- 线程上下文隔离彻底，但 无法自动继承 ThreadLocal（如用户身份、traceId），需手动透传
- 开销略高：线程创建、调度、上下文切换，不过 Netflix 实践表明，在合理配置下（如每线程池 5–20 线程）影响可控
信号量隔离：适合可信、极快、纯内存或本地调用
所有逻辑仍在原始调用线程中执行，仅靠一个计数器（Semaphore）限制最大并发数。一旦达到阈值，立刻拒绝新请求，走 fallback。
- 零线程创建开销，轻量高效，适合高频调用（例如查本地缓存、配置中心、状态校验）
- 不支持超时控制——如果依赖卡死，当前线程就会一直等，直到它自己抛异常或返回
- 只能同步执行，不支持异步；也不能脱离当前线程上下文，ThreadLocal 可直接使用
- 信号量值可动态调整（比如运行时降级限流），而线程池大小启动后基本固定
- 适用于调用方完全信任下游稳定性且响应稳定在毫秒级的场景，否则容易因单点卡顿拖垮整个线程
怎么选？关键看三个问题
不用背规则，现场问自己：
- 这个依赖会不会超时？如果会，必须选 线程隔离
- 这个调用是不是网络 IO（HTTP/Dubbo/DB）？如果是，优先 线程隔离
- 这个操作是不是本地方法、内存计算、或已确认 SLA ≤ 5ms 的内部服务？那 信号量隔离更合适
配置上的一句提醒
默认策略是 THREAD（线程池），要切信号量，得显式配置：
hystrix.command.default.execution.isolation.strategy=SEMAPHORE
同时设好信号量上限：
hystrix.command.default.execution.isolation.semaphore.maxConcurrentRequests=20
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
