barrier专为多轮同阶段全参与者汇合设计，不可替代manualresetevent等；participantcount是初始化契约基数，不可修改当前轮约束；signalandwait()返回调用前阶段号；post-phase委托须轻量且不可抛异常；dispose()后调用会直接抛出objectdisposedexception。
Barrier 不是用来替代 ManualResetEvent 或 CountdownEvent 的通用等待工具，它专为「多轮、同阶段、全参与者汇合」设计。用错场景或忽略其生命周期约束，轻则线程永久挂起，重则引发静默死锁。
Barrier 构造时 participantCount 为什么不能改？
初始化时传入的 participantCount 是屏障的“契约基数”，不是计数器——它定义了每一轮必须到达的**最小完整集合**。Barrier 内部不维护“已到达/未到达”的布尔快照，而是依赖原子状态机驱动阶段跃迁。一旦构造完成，这个数就固化在实例状态里，后续调用 AddParticipant() 或 RemoveParticipant() 实际是动态调整下一轮的契约基数，而非修改当前轮约束。
常见误用：
- 在某线程提前退出后，只调用
RemoveParticipant()就认为“本轮安全了”——错。已阻塞在SignalAndWait()的其他线程仍按原基数等待，不会感知变更 - 并发调用
AddParticipant()多次，但没同步控制——可能触发InvalidOperationException，因为 Barrier 要求增减操作本身是线程安全的，但逻辑上需由单一协调者驱动 - 把
participantCount设为 1 来“模拟单线程流程”——毫无意义，SignalAndWait()会立即返回，失去屏障语义
SignalAndWait() 返回值 CurrentPhaseNumber 容易被误解
SignalAndWait() 返回的是**调用前**的阶段号（从 0 开始），不是“本次抵达后的新阶段”。这意味着：若你在回调委托里读 barrier.CurrentPhaseNumber，它和返回值一致；但若在回调执行完毕、线程继续运行后再次读取，它已是 +1 后的值。
典型陷阱：
- 在回调中做日志，写
Console.WriteLine($"Phase {barrier.CurrentPhaseNumber}")，结果输出全是 0、1、2……看似正常，但误以为这是“本轮编号”，其实它只是“刚完成的那轮编号” - 用返回值做数组索引（如
results[barrier.SignalAndWait()] = data），若线程调度稍慢，可能因阶段已推进导致越界 - 依赖返回值判断“是否首轮”，应改用
barrier.CurrentPhaseNumber == 0，更直观且不易受调用时机干扰
Post-phase 委托里不能 throw 异常，也不能阻塞太久
回调委托由**最后一个到达的线程**同步执行，其他所有线程仍在 SignalAndWait() 内部阻塞等待该委托结束。因此，这个委托本质上是整个屏障的“临界区瓶颈”。
必须注意：
- 委托内抛出未捕获异常 → 整个
SignalAndWait()调用栈崩溃，其他线程仍卡在等待中，形成“半释放”死锁 - 委托里做耗时 I/O（如写文件、发 HTTP 请求）→ 所有线程一起等，严重拖慢吞吐，违背并行初衷
- 委托中调用另一个
SignalAndWait()→ 极大概率引发嵌套死锁，Barrier 不支持重入 - 正确做法：只做轻量聚合（如合并内存数组）、设置共享标志、生成下轮输入——全部控制在毫秒级
Barrier.Dispose() 后再 SignalAndWait() 会直接炸
Barrier 实现了 IDisposable，但它的释放不是“软停机”。一旦调用 Dispose()，内部所有同步状态被强制清零，后续任何 SignalAndWait() 都会立即抛出 ObjectDisposedException，且无法恢复。
现实问题：
- 在
using块里创建 Barrier，但线程还在跑 ——Dispose()提前触发，活跃线程全崩 - 多个线程共用一个 Barrier，某线程认为“任务结束”就 Dispose，其余线程还不知情
- 没有明确的“所有线程已退出”信号机制，不敢贸然 Dispose
稳妥方案：只在确认所有参与线程已终止（如通过 Thread.Join() 或 Task.WaitAll()）后再调用 Dispose()；若生命周期不确定，干脆不 Dispose——Barrier 本身无非托管资源，GC 可安全回收。
