Polly的Bulkhead隔离是限制并发数的策略，解决依赖服务慢响应拖垮调用方线程池的问题；通过maxParallelization和maxQueuingActions控制并发与排队，需单例复用且常与熔断器外层组合。
什么是Polly的Bulkhead隔离，它解决什么问题
Bulkhead（舱壁）隔离是Polly中用于限制并发执行数量的策略，核心目标不是“重试”或“降级”，而是防止某个依赖服务的慢响应或超时拖垮整个调用方线程池。典型场景：你有10个HTTP客户端并发调用一个不稳定的第三方API，若不限制，可能瞬间耗尽线程池，导致其他正常请求（比如用户登录）也卡死。BulkheadPolicy通过设定最大并发数（maxParallelization）和等待队列长度（maxQueuingActions），把故障影响控制在“舱室”内。
如何创建并使用BulkheadPolicy执行同步/异步操作
注意：Polly v8+ 已将 BulkheadPolicy 移入独立命名空间 Polly.Bulkhead，且不再支持同步执行（即无 Execute 方法），只保留 ExecuteAsync —— 这是设计使然，因为同步舱壁在.NET线程模型下难以安全实现。
实操要点：
- 必须用
AddBulkhead扩展方法（如搭配PolicyRegistry）或直接构造BulkheadPolicy -
maxParallelization建议设为依赖服务的合理吞吐上限（例如该API SLA承诺100 QPS，则设为20–30，留余量） -
maxQueuingActions不宜过大，否则排队过长反而掩盖响应恶化；设为0表示拒绝排队，立即抛BulkheadRejectedException - 务必捕获
BulkheadRejectedException并做降级（如返回缓存、空值或 fallback API）
var bulkhead = Policy.BulkheadAsync(5, 10); // 最多5个并发，最多10个排队
try
{
await bulkhead.ExecuteAsync(async () => await httpClient.GetAsync("https://api.example.com/data"));
}
catch (BulkheadRejectedException)
{
// 降级逻辑：返回本地缓存或默认值
return GetFallbackData();
}
Bulkhead与CircuitBreaker组合使用的常见错误
很多人想“先熔断再限流”，但顺序错了——Bulkhead应放在外层，CircuitBreaker放内层。否则当熔断器打开后，Bulkhead仍会持续接收请求并排队，直到队列满才拒绝，失去隔离意义。
正确组合方式：
- 外层：Bulkhead 控制总并发压力
- 内层：CircuitBreaker 检测下游稳定性（如连续失败触发熔断）
- 两者都需独立配置异常处理，尤其
BulkheadRejectedException不能被内层CircuitBreaker捕获
<pre class="brush:php;toolbar:false;">var breaker = Policy.Handle<HttpRequestException>()
.CircuitBreakerAsync(3, TimeSpan.FromMinutes(1));
var bulkheadThenBreaker = Policy.WrapAsync(bulkhead, breaker);
为什么Bulkhead在ASP.NET Core托管服务中容易失效
在 IHostedService 或后台任务中直接用 <code>BulkheadPolicy，常出现“限制不生效”现象。根本原因是：这些服务通常运行在 ThreadPool 线程上，而 BulkheadPolicy 的计数器是 per-policy 实例的，若每次调用都 new 一个新 policy，隔离就完全失效。
关键约束：
-
BulkheadPolicy必须单例复用（注册为Singleton） - 不要在
using块里创建，也不要每次请求 new 一个 - 若需多组隔离（如按租户分舱），应预定义多个命名 policy 并注入
PolicyRegistry
真正难的是动态配额调整和实时监控——Polly本身不暴露当前并发数，得靠自定义 OnBulkheadRejected 回调打日志或推指标，这点很容易被忽略。
