Java中throw抛出的异常不会自动转为BulkheadFullException，该异常仅由Resilience4j的Bulkhead在并发超限时主动抛出；手动throw与Bulkhead无关，需通过fallback按类型区分处理。
Java 中 throw 抛出的异常本身**不会自动转换为 BulkheadFullException**，因为 BulkheadFullException 是 Resilience4j 框架中 Bulkhead 组件在**并发请求数超过配置阈值时内部主动抛出的特定异常**，而非对用户抛出异常的“转换”结果。
BulkheadFullException 的触发时机
BulkheadFullException 仅在以下情况发生：
- 你使用了 Resilience4j 的
Bulkhead（如ThreadPoolBulkhead或SemaphoreBulkhead）包装执行逻辑； - 当前并发调用数已达最大允许数（
maxConcurrentCalls或线程池已满）； - 新请求尝试进入时被拒绝，此时 Bulkhead 主动抛出
BulkheadFullException。
它与你代码中手动 throw new RuntimeException(...) 无关——后者会原样传播（除非被 fallback 或异常映射拦截），不会“变成” BulkheadFullException。
如何让业务异常“表现得像”被 Bulkhead 拒绝？
如果你希望在某些业务条件下（例如校验失败、资源不可用等）**模拟 Bulkhead 拒绝效果**，可手动抛出 BulkheadFullException，但需注意：这不是标准用法，且可能干扰监控和重试逻辑。示例：
立即学习“Java免费学习笔记（深入）”；
Bulkhead bulkhead = Bulkhead.of("myService", BulkheadConfig.custom()
.maxConcurrentCalls(10)
.build());
Supplier<String> decorated = Bulkhead.decorateSupplier(bulkhead, () -> {
if (someBusinessCondition()) {
// 主动模拟熔断/拒绝（不推荐常规使用）
throw new BulkheadFullException("Business rule blocked entry");
}
return callExternalService();
});
正确处理 throw 异常 + Bulkhead 协同的方式
更合理的做法是：让 throw 的异常与 Bulkhead **共存、分层处理**：
-
Bulkhead 负责控制并发量：超限时抛
BulkheadFullException； -
你的业务代码负责自身逻辑异常：如
throw new IllegalArgumentException()； -
用 Retry / Fallback 区分处理：例如用
Retry重试业务异常，而对BulkheadFullException直接 fallback 返回降级值。
Resilience4j 支持按异常类型配置 fallback：
Supplier<String> decorated = Decorators.ofSupplier(this::callService)
.withBulkhead(bulkhead)
.withFallback(throwable -> {
if (throwable instanceof BulkheadFullException) {
return "Service busy, try later";
} else if (throwable instanceof IOException) {
return "Network error, using cache";
}
return "Unknown error";
})
.decorate();
常见误区提醒
- ❌ 认为
throw会“触发” Bulkhead 拒绝 —— 不会，Bulkhead 拒绝只取决于并发计数； - ❌ 在 Bulkhead 内部
throw new BulkheadFullException()来“伪装”拒绝 —— 这绕过了 Bulkhead 的状态统计，导致指标失真； - ✅ 正确思路：Bulkhead 控制入口流量，业务异常在内部抛出，再由外层的 fallback/retry 分类响应。
