callnotpermittedexception 并非由 throw 的异常转换而来，而是熔断器在 open 状态下拦截调用时主动抛出；其触发前提是配置的失败异常（如 runtimeexception）导致熔断开启，后续调用直接拒绝并抛此异常。
Java 中 throw 抛出的异常本身不会自动变成 CallNotPermittedException，这个转换是由熔断器（如 Resilience4j 的 CircuitBreaker）在**拦截方法调用并检测到熔断开启状态时主动抛出的**，而不是对原始异常做“转换”。关键在于：你手动 throw 的异常是否被熔断器视为失败信号，从而影响熔断状态；而 CallNotPermittedException 是在后续调用中、熔断器处于 OPEN 或 HALF_OPEN 且拒绝执行时才抛出的。
熔断器如何决定是否开启熔断
Resilience4j 的 CircuitBreaker 默认只将特定异常（如 RuntimeException、Exception）或满足条件的异常视为“失败”，进而增加失败计数。它不会把你的异常“转成”CallNotPermittedException，而是根据失败率等规则切换状态。
- 默认情况下，所有
Throwable都算失败（可配置recordFailurePredicate） - 当失败率达到阈值，熔断器从
CLOSED→OPEN - 进入
OPEN后，所有新请求直接被拒绝，此时才抛CallNotPermittedException
确保你的 throw 异常能触发熔断
如果你 throw new IllegalArgumentException("xxx") 却没导致熔断，大概率是异常未被记录为失败。需显式配置：
- 使用
CircuitBreakerConfig.custom().recordExceptions(IllegalArgumentException.class) - 或自定义 predicate：
.recordFailure(e -> e instanceof IllegalArgumentException) - 避免只捕获并吞掉异常——熔断器无法感知失败
CallNotPermittedException 是调用被拒绝时抛出的，不是“转换”来的
它和你 throw 的异常无关，而是熔断器在 OPEN 状态下拦截方法调用时主动抛出的运行时异常：
- 调用被装饰的方法（如
circuitBreaker.decorateSupplier(...).get()） - 若当前状态为
OPEN，不执行原逻辑，直接抛CallNotPermittedException - 该异常继承自
RuntimeException，无需声明，但建议 catch 处理降级逻辑
典型使用示例（Resilience4j）
正确配置 + 调用流程：
CircuitBreaker circuitBreaker = CircuitBreaker.ofDefaults("backendService");
// 包装业务逻辑
Supplier<string> decorated = circuitBreaker.decorateSupplier(() -> {
// 这里 throw 的异常会被记录，可能触发熔断
if (someCondition) {
throw new RuntimeException("service unavailable");
}
return "success";
});
// 第一次调用失败 → 计入失败统计 → 达阈值后熔断开启
// 后续调用：circuitBreaker.state() == OPEN → 直接抛 CallNotPermittedException
try {
String result = decorated.get();
} catch (CallNotPermittedException e) {
// 处理熔断拒绝，例如返回缓存或默认值
return "fallback";
}
</string>
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
