std::barrier是c++20引入的可重用线程同步原语，用于让一组线程在指定点集体等待直至全部到达后才一同继续；与一次性使用的std::latch不同，它支持多轮复用，构造时需指定非零预期线程数，且无超时机制。
std::barrier 是什么，和 std::latch 有什么区别
它是一个线程同步原语，用来让一组线程在某个点“集体等待”，直到所有线程都到达（arrive）后才一起放行。和 std::latch 不同，std::barrier 可重用——一次 wait 返回后，内部计数自动重置，下一轮还能继续用；而 std::latch 是一次性消耗品。
常见错误现象：想反复等多轮线程汇合，却用了 std::latch，结果第二轮调用 wait() 直接卡死或未定义行为。
- 适用场景：并行计算中的迭代式任务（比如每轮做局部计算 → 同步 → 汇总 → 下一轮）
-
std::barrier构造时必须指定参与线程数（expected），不能为 0 或负数，否则抛std::invalid_argument - 如果某线程在
arrive()前就退出（比如异常或 return），会导致其他线程永久阻塞——没有超时机制，也没办法“取消”等待
怎么正确初始化和触发 barrier 等待
构造时传入预期线程数，每个线程调用 arrive() 或 arrive_and_wait()。后者是原子操作：先抵达、再阻塞、等全员齐后才返回。
性能影响：每次 arrive_and_wait() 都涉及原子计数和条件变量唤醒，频繁调用（如每微秒一次）会明显拖慢吞吐；若只是通知“我到了”，用 arrive() 更轻量。
立即学习“C++免费学习笔记（深入）”；
- 推荐写法：
barrier.arrive_and_wait()—— 简洁、不易漏掉 wait - 不推荐在循环里混用
arrive()和wait()，容易因顺序错乱导致死锁 - 如果需要在等待时执行回调（比如汇总数据），构造时传入一个可调用对象，它会在最后一个线程抵达、但尚未唤醒其余线程前执行——注意：此时其他线程仍处于阻塞中，回调里别做耗时或加锁操作
为什么 barrier.wait() 有时卡住不动
最常见原因是线程数量对不上：构造时写了 4，但实际只启动了 3 个线程调用 arrive()，第 4 个根本不存在，那剩下 3 个就永远等不到“第 4 个”。
另一个隐蔽坑：线程函数里没捕获异常，导致某个线程在抵达 barrier 前崩溃退出，等同于“少一人到场”。
- 检查方式：在每个线程入口打日志，确认
arrive_and_wait()确实被执行到 - 不要依赖主线程“数着线程数启动”，改用
std::vector<:thread></:thread>显式管理，并确保每个join()前都完成 barrier 同步 - Windows 上某些旧版 MSVC（如 19.29 之前）对
std::barrier实现有 bug，表现为虚假唤醒或 hang，建议升级到 19.30+
std::barrier 在 C++17/20 中的可用性与替代方案
std::barrier 是 C++20 引入的，C++17 及更早标准里没有。如果你用的是 GCC 10+、Clang 12+ 或较新 MSVC，且编译选项开了 -std=c++20，就能直接用。
兼容性 fallback 方案有限：不能简单用 std::mutex + std::condition_variable 手写一个完全等价的可重用 barrier（因为要精确控制唤醒时机和避免 spurious wakeups），但可以用 std::latch 模拟单次 barrier（需每次 new 一个新对象）。
- 跨平台项目若暂不支持 C++20，建议封装一层宏判断：
#if __cpp_lib_barrier >= 201907L - 别试图用
std::semaphore替代——它无法保证“全员到齐才放行”，只能控并发数 - 真实项目中，比 barrier 更常被忽略的是线程生命周期管理：barrier 对象本身必须活过所有线程的最后一次
arrive()，否则析构时可能引发 UB
