Java异常机制本身不直接提供断路器功能，但与断路器模式深度协同：异常是触发状态切换的关键信号，断路器决定是否传播异常或执行降级；需在业务层嵌入状态管理、阈值判断与跃迁逻辑，结合异常语义分类（可重试、不可恢复、熔断触发）、显式注解保护、匹配SLA的配置及状态联动日志实现高可用。
Java 中的异常机制本身不直接提供断路器功能，但它与断路器模式深度协同：异常是触发状态切换的关键信号，而断路器则决定了“是否让异常继续传播”或“是否拦截并执行降级逻辑”。真正实现业务层级断路器，需在异常处理流程中嵌入状态管理、阈值判断和状态跃迁逻辑，而非仅靠 try-catch。
用异常作为断路器的状态触发器
断路器不是替代异常处理，而是对特定异常做语义化分类和响应。关键在于区分三类异常：
- 可重试异常（如 ConnectException、SocketTimeoutException）：适合配合重试 + 断路器，失败后计入统计，但不立即跳闸
- 不可恢复异常（如 IllegalArgumentException、4xx 响应封装的业务异常）：通常不计入断路器失败计数，避免误判服务故障
- 熔断触发异常（如 CircuitBreakerOpenException）：由断路器主动抛出，表示当前拒绝调用，此时业务层应直接走 fallback 或返回友好提示
例如，在调用支付服务时，若捕获到 IOException，应视为基础设施异常，纳入失败统计；若捕获到 PaymentRejectedException（业务自定义），则说明支付已明确拒绝，不应影响断路器状态。
在业务方法中嵌入断路器调用逻辑
不要把断路器当成“兜底装饰器”，而要让它成为业务决策的一部分。推荐在 Service 层关键路径上显式使用：
- 用 Resilience4j 的
@CircuitBreaker(name = "paymentService")注解修饰核心远程调用方法，配合@Fallback指定降级方法 - 降级方法必须是同一类中
public且签名兼容的方法，返回默认订单状态、缓存数据或空对象，而非抛出新异常 - 避免在 controller 层做断路判断——那属于横切关注点，应下沉到 service 或 client 封装层
示例中，orderService.createOrder() 内部调用 paymentClient.charge()，后者被断路器保护；一旦跳闸，自动转至 chargeFallback() 返回 “支付通道暂不可用，请稍后再试”，前端据此展示对应 UI，不报错也不卡死。
配置需匹配业务容忍度，而非套用默认值
断路器参数不是技术指标，而是业务 SLA 的代码表达：
- failureRateThreshold = 40 表示允许连续 10 次调用中最多 4 次失败——适用于非强实时场景（如优惠券发放）
- waitDurationInOpenState = 30s 意味着服务至少有半分钟自我修复窗口——比秒级超时更符合运维实际
- slidingWindowSize = 20 配合 minimumNumberOfCalls = 10 可防止冷启动误熔断（前 9 次失败不统计，第 10 次起才开始滚动计算）
电商大促期间可临时调低 failureRateThreshold 至 20，宁可早熔断，也不让下游库存服务被雪崩拖垮；日常则设为 50，兼顾稳定性与可用性。
异常日志与断路器状态必须联动可观测
单看异常日志无法判断是瞬时抖动还是已熔断。应在每次状态变更时记录结构化日志：
- CLOSED → OPEN：记录 “circuit breaker [paymentService] opened due to 5/10 failures in last 60s”
- OPEN → HALF_OPEN：记录 “circuit breaker [paymentService] entering half-open after 30s timeout”
- HALF_OPEN → CLOSED：记录 “circuit breaker [paymentService] closed: 3 consecutive successes”
同时，在 catch 块中打印异常堆栈时，附加当前断路器状态：log.warn("Failed to call payment, circuit state: {}", circuitBreaker.getState(), ex)。这样排查问题时，一眼可知是服务真挂了，还是断路器在主动保护。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
