std::barrier构造时必须预先指定固定参与线程数，不可动态增减；需严格匹配arrive()调用次数，否则卡死或抛异常；支持arrive_and_drop()主动退出，但drop后不可再arrive；无超时wait，不支持轮询，适用多轮同步场景。
std::barrier 构造时必须指定参与线程数
它不是“自动感知线程数量”的同步点，而是靠构造时传入的 expected 值硬编码等待人数。一旦构造完成，这个值就固定了，不能增减线程——想动态调整就得换用 std::latch 或手写逻辑。
常见错误是把 std::barrier 当成可重用的“信号量”，结果某次 arrive() 后没线程再调用，后续 wait() 就永远卡住；或者误以为能在线程启动后才决定人数，实际必须在所有线程共享 barrier 实例前就定死。
- 初始化时传 4，就必须恰好有 4 个线程调用
arrive()才会集体释放 - 少于 4 次调用 → 卡死；多于 4 次 →
std::system_error（错误码为std::errc::invalid_argument） - 若线程可能提前退出，得配合
arrive_and_drop()主动减少计数，否则 barrier 永远等不满
arrive() 和 arrive_and_drop() 的行为差异很关键
arrive() 是常规抵达：计数减一，若归零则触发所有等待线程继续，并重置内部计数器（barrier 可重复使用）；arrive_and_drop() 则是“永久退群”——不仅减一，还把 expected 值也减一，后续再没人能凑满原定人数。
典型场景是 worker 线程池中某些任务提前失败需撤离：不 drop 就会导致剩余线程永远等不到它，整个 barrier 卡住；但滥用 drop 又会让 barrier 提前释放，破坏同步语义。
立即学习“C++免费学习笔记（深入）”；
- 正常协作流程用
arrive() - 线程确定不再参与后续同步轮次时，用
arrive_and_drop() - drop 后不能再对这个 barrier 调用
arrive()，否则未定义行为
wait() 阻塞直到所有预期线程到达，且无超时版本
std::barrier 没有带 timeout 的 wait_for() 或 wait_until()，只有阻塞式 wait()。这意味着一旦逻辑出错（比如漏调 arrive()），线程就彻底挂起，无法靠超时探测问题。
调试时容易忽略这点，尤其在异常路径里忘了调 arrive()。建议在关键路径用 RAII 包装，比如局部对象在析构时自动 arrive()，避免裸调用遗漏。
- 没有
try_wait()，不能轮询 - 不能用在需要响应中断或取消的场景（如 std::jthread 的 stop_token 不直接兼容 barrier）
- 若需超时控制，得在外层加
std::condition_variable+std::mutex自行实现，代价不小
与 std::latch 和 std::semaphore 的适用边界
std::barrier 的核心价值是“多轮复用+自动重置”，而 std::latch 是一次性倒计时，std::counting_semaphore 更偏向资源计数而非线程协作。选错类型会导致逻辑别扭甚至死锁。
比如做 N 个线程分阶段计算：第一阶段全做完才能进第二阶段，且要循环 10 轮——这时 std::barrier 最自然；如果只等一次初始化完成，std::latch 更轻量；如果控制的是数据库连接数这类资源，则该用 std::counting_semaphore。
- 需要“到达即重置、反复用” →
std::barrier - 只需“等一次、之后永远满足” →
std::latch - 需要 acquire/release 资源配额，或跨线程传递许可 →
std::counting_semaphore
barrier 的重置行为是隐式的，也是最容易被忽视的复杂点：它不靠用户手动 reset，而是在每次计数归零后自动准备好下一轮。但这个“自动”依赖所有线程严格遵守约定——少一次 arrive()，后面所有轮次全崩。
