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