线程池隔离（hystrix）性能开销大，因线程切换、上下文保存和池管理导致延迟与gc压力；信号量隔离（sentinel）更轻量，适合io密集型场景，但无法中断慢启动，需配合rt熔断补位。
线程池隔离 vs 信号量隔离：性能开销差在哪
Hystrix 默认用 THREAD 隔离（线程池），每个服务调用都扔进独立线程池；Sentinel 默认用 SEMAPHORE 隔离（即并发线程数限流），不创建新线程，只计数当前正在执行的线程数。
这意味着：Hystrix 的线程切换、上下文保存、线程池维护会带来明显延迟和 GC 压力；而 Sentinel 在高并发场景下更轻量，尤其适合 IO 密集型接口（如 HTTP 调用、Redis 查询）。
- 别在 Hystrix 里盲目加大
coreSize，容易拖垮 JVM 线程数（默认 10 个线程池 × 10 线程 = 100 线程，再加业务线程就超了） - Sentinel 的
@SentinelResource不自动开启线程池，想模拟 Hystrix 那种“完全隔离”，得手动配ThreadCount流控规则 + fallback 逻辑，不是开箱即用 - 信号量隔离无法拦截慢启动（比如数据库连接池初始化耗时），Hystrix 的线程池能靠超时直接中断——这点 Sentinel 需配合响应时间熔断来补位
熔断触发条件：失败率 ≠ 响应时间失控
Hystrix 只认一个硬指标：circuitBreaker.errorThresholdPercentage（错误率 ≥50% 且请求量 ≥20 才熔断）；Sentinel 支持三套并行策略：DEGRADE_GRADE_RT（平均响应时间 > 1s）、DEGRADE_GRADE_EXCEPTION_RATIO（异常比例）、DEGRADE_GRADE_EXCEPTION_COUNT（异常数）。
真实微服务中，接口卡顿比直接报错更危险——它不抛异常，但把线程池/连接池慢慢占满。Hystrix 对这种“假活真堵”毫无感知；Sentinel 的 RT 熔断能在平均响应飙升时立刻降级，防雪崩更主动。
立即学习“Java免费学习笔记（深入）”；
- Hystrix 熔断后必须等
sleepWindowInMilliseconds=5000才试半开，期间所有请求全拒；Sentinel 半开探测是自动的，且可配置探测间隔与成功阈值 - 注意 Sentinel 的 RT 统计基于滑动窗口（默认 1 秒切 20 个 50ms 小窗），比 Hystrix 的滚动桶（固定 10s 桶）更灵敏；但若接口本身 RT 波动大（如搜索类），需调高
minRequestAmount避免误熔断 - 两者都不支持“按下游服务等级熔断”（比如只对非核心服务降级），得靠自定义
Context或规则分组实现
规则动态化：注解写死 ≠ 控制台热推
Hystrix 规则基本靠 @HystrixCommand 注解硬编码，改一次就得发版；Sentinel 把资源定义（@SentinelResource）和规则（限流值、熔断阈值）彻底解耦，天然支持 Nacos/Apollo 动态推送，也自带 Dashboard 实时编辑。
面试常问“怎么做到不停机调限流值？”——答案不是“加个配置中心”，而是看框架是否允许运行时覆盖规则。Hystrix 需集成 Archaius + 自定义 PropertyListener；Sentinel 只需在控制台点几下，或调 FlowRuleManager.loadRules() API。
- Sentinel 控制台默认不持久化规则，重启就丢；生产必须对接 Nacos 并开启
sentinel.datasource.ds.nacos.groupId配置 - Hystrix Dashboard 已停止维护，Turbine 聚合也难适配 Kubernetes Service Mesh 场景；Sentinel Dashboard 原生支持集群监控和机器列表筛选
- 别以为加了
@SentinelResource就万事大吉——没配规则等于没保护；而 Hystrix 加了注解至少有默认熔断（失败率 50%，窗口 10s）
为什么现在面试总问这个？因为 Hystrix 已停更，Sentinel 是事实标准
Netflix 官方在 2018 年宣布 Hystrix 进入维护模式，2023 年后连关键 Bug 都不再修；Spring Cloud Alibaba 明确将 Sentinel 作为容错组件首选，Spring Cloud 2022+ 版本已移除 Hystrix Starter。
但要注意：Sentinel 并非 Hystrix 的“平替”。它弱化了线程级故障隔离，强化了流量维度治理。如果你的系统正从单体转向云原生，关注点该从“某个服务挂了怎么不传染”转向“入口 QPS 突增 3 倍时，如何保核心链路不垮”——这才是 Sentinel 的设计原点。
真正容易被忽略的是：Sentinel 的系统自适应保护（Load 限流）依赖 Linux /proc/loadavg，在 Docker 容器里默认不可见，需加 --privileged 或挂载 /proc 才生效；而这点 Hystrix 根本不涉及。
