应选SemaphoreBulkhead控制同步HTTP调用并发，因其零线程开销、适用于RestTemplate/WebClient等轻量阻塞场景；而ThreadPoolBulkhead仅用于需独立线程的CPU密集型或必须规避主线程阻塞的异步长耗时任务。
直接结论：用 SemaphoreBulkhead 控制同步调用并发数，或用 ThreadPoolBulkhead 隔离异步/长耗时操作；两者必须配合超时（TimeLimiter）和熔断（CircuitBreaker）才真正防雪崩。
什么时候该选 SemaphoreBulkhead 而不是 ThreadPoolBulkhead
信号量模式适用于绝大多数同步 HTTP 调用场景，比如调用下游支付、库存、用户中心等 REST 接口。它不创建新线程，只靠计数器控制进入临界区的请求数，开销极小、无上下文切换成本。
- 适用：
RestTemplate、WebClient同步/异步调用，数据库连接获取，本地缓存刷新等轻量阻塞操作 - 不适用：需要真正独立线程执行的 CPU 密集型任务（如大文件解析、图像处理），或必须规避主线程阻塞的场景
- 常见错误：在 Spring WebFlux 中误用
ThreadPoolBulkhead—— 它会破坏响应式链，导致线程泄漏和背压失效
maxConcurrentCalls 和 maxWaitDuration 怎么设才不踩坑
这两个参数不是拍脑袋定的。设太小，正常流量就被拒；设太大，起不到隔离效果。关键依据是下游服务的 SLO 和你自身的线程池水位。
-
maxConcurrentCalls建议值 = 下游服务能稳定支撑的并发数 × 0.7（留缓冲），例如库存服务压测显示能扛 50 QPS，那这里可设为 35 -
maxWaitDuration必须小于你整个接口的 SLA 超时时间，比如对外承诺 800ms 响应，这里最多设 300ms，否则等待本身就会拖垮上游 - 生产环境严禁设为
-1或Duration.ofSeconds(Long.MAX_VALUE)—— 这等于放弃保护，所有请求排队堵死
为什么单独用 Bulkhead 无法防雪崩
舱壁只管“进多少”，不管“卡多久”或“错多少”。一个被舱壁放行的请求，如果下游服务响应慢到 10 秒，它仍会占着你的线程/连接不放；如果连续失败，故障还会持续扩散。
- 必须搭配
TimeLimiter：给每个调用设硬性超时（如timeoutDuration: 2s），超时立即中断 - 必须搭配
CircuitBreaker：当失败率超过阈值（如 50%），直接熔断后续请求，避免反复试探已瘫痪的服务 - 示例组合（YAML）：
resilience4j.bulkhead: configs: default: max-concurrent-calls: 20 max-wait-duration: 100ms resilience4j.timelimiter: configs: default: timeout-duration: 2s resilience4j.circuitbreaker: configs: default: failure-rate-threshold: 50 minimum-number-of-calls: 20
动态调整 Bulkhead 参数在生产中有多难
别信“自动扩缩容 Bulkhead”的宣传。真实生产里，它的阈值几乎从不 runtime 变更 —— 因为并发上限依赖下游容量、本机线程池大小、GC 压力等静态因素，实时调参极易引发抖动。
- 真正可行的是：基于 Prometheus 指标（如
resilience4j.bulkhead.calls的failed和permitted计数器）配置告警，人工评估后发布新配置 - 绝对避免通过 Actuator endpoint 热更新
BulkheadConfig—— 多个实例配置不同步会导致流量倾斜和指标失真 - 最容易被忽略的一点：
SemaphoreBulkhead不感知 I/O 阻塞，它只管“进入”，不关“出来”。所以即使你设了 10 并发，若下游全卡在 socket read 上，你的连接池照样可能耗尽 —— 这时候得靠 OkHttp 连接池或 HikariCP 的connection-timeout来兜底
