熔断机制通过失败率阈值（如10次中失败6次）、精准异常识别、滑动时间窗口等量化指标主动切断调用链路，配合resilience4j实现细粒度控制、有效降级与完备监控。
当下游服务频繁抛出异常，Java 应用不能被动重试或无限等待，必须主动切断调用链路——这就是熔断机制的核心作用。它不是单纯捕获异常，而是基于失败统计做状态决策，把“异常多”转化为“主动不调用”，从而保护自身线程、连接池和响应能力。
明确熔断触发条件：别只看异常类型，要看失败模式
单纯 catch Exception 并不够。熔断依赖可量化的失败指标：
- 失败率阈值：比如最近 10 次调用中，有 6 次抛出 IOException、TimeoutException 或业务定义的 RemoteServiceException，失败率达 60%（超过设定的 50%）
- 失败类型需精准识别：网络超时、连接拒绝、HTTP 5xx 应纳入统计；而 400/401 等客户端错误通常不计入，避免误熔断
- 时间窗口要合理：用滑动窗口（如 COUNT_BASED 的 10 次）比固定周期更灵敏；避免用“过去一分钟失败 5 次”这类易受毛刺干扰的规则
选择轻量且可控的熔断器实现：Resilience4j 是当前主流推荐
Hystrix 已停止维护，Sentinel 功能强但偏重平台集成。对多数 Spring Boot 项目，Resilience4j 更适合嵌入式、细粒度控制：
- 配置失败率阈值、半开探测窗口、冷却时间，全部通过代码或 YAML 控制，无需额外组件
- 天然适配函数式调用：把远程调用封装成 Supplier、Function，再用 CircuitBreaker.decorateSupplier 包裹
- 失败后自动跳过真实请求，直接执行 recover 逻辑，不占用线程或连接资源
降级逻辑必须真实可用，不能只是日志或空返回
熔断打开后，用户仍需得到响应。降级不是兜底摆设，而是有业务意义的替代路径：
- 查商品详情失败 → 返回本地缓存的旧价格 + 标注“数据可能已过期”
- 用户中心不可用 → 用 sessionId 解析基础身份信息，跳过权限校验（仅限非敏感操作）
- 推荐服务异常 → 切换为热门榜单或静态规则生成结果
- 关键点：降级返回值类型必须与原接口一致，且不能引发新异常
监控与人工干预通道不能缺失
熔断是自动机制，但不能完全脱离人眼：
- 暴露 /actuator/circuitbreakers 端点（Spring Boot Actuator + Resilience4j），实时查看各熔断器状态、失败计数、最近一次状态切换时间
- 对接 Prometheus + Grafana，设置告警：某个熔断器持续处于 OPEN 超过 2 分钟，说明下游已长时间不可用，需介入排查
- 提供运维 API（如 POST /admin/circuit-breaker/{name}/reset），支持紧急手动重置，避免半开探测未生效时的被动等待
不复杂但容易忽略：熔断本身不解决下游问题，它只是给系统争取喘息时间。真正稳定，靠的是熔断 + 可观测性 + 快速定位 + 下游修复闭环。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
