std::barrier通过arrive_and_wait()实现多线程集体等待，达阈值后全部唤醒并自动重置；std::latch为一次性计数器，count_down()归零后wait()立即返回，不可重用。
std::barrier 怎么让多个线程在某个点集体等待？
std::barrier 是一个可重用的同步点，所有参与线程调用 arrive_and_wait() 后会阻塞，直到指定数量的线程都到达，然后全部同时被唤醒。它适合循环中反复使用的场景，比如并行计算的每一轮迭代同步。
- 构造时必须传入参与线程数（
std::barrier<T> b{N}），这个N是“到达阈值”，不是线程对象数，需确保恰好有N次arrive_and_wait()调用 - 每次唤醒后状态自动重置，下一轮可继续用，无需重建
- 可选提供回调函数（
std::barrier<T> b{N, []{ /* 仅在最后一人到达时执行一次 */ }};），该回调在最后一个线程到达、但所有线程尚未被唤醒前执行，常用于聚合结果或刷新共享状态 - 若某线程提前退出（如抛异常），未调用
arrive_and_wait()，则其余线程永久阻塞 —— 这是常见死锁源头
std::barrier b{3};
std::vector<std::thread> ts;
for (int i = 0; i < 3; ++i) {
ts.emplace_back([&b]{
// 各自做些事
std::this_thread::sleep_for(100ms * (i+1));
b.arrive_and_wait(); // 全部到这里等齐才继续
// 继续后续操作
});
}
for (auto& t : ts) t.join();std::latch 为什么只能用一次？
std::latch 是一次性计数器，初始值为 N，每次调用 count_down() 减一，当值归零时所有等待线程立即被唤醒；之后再调用 wait() 会立刻返回，count_down() 也无效果。它适合“等待 N 个前置任务完成”的单次协调场景，比如启动阶段初始化依赖。
- 不能重置，也不能获取当前计数值（没有
get_count()）—— 设计上就是“只降不升、只用一次” - 线程可调用
count_down()多次，只要总减量 ≥ 初始值，就足以触发释放；但通常每个参与者只调一次 - 如果某个线程忘记调用
count_down()，其他调了wait()的线程就会永远卡住 —— 和barrier类似，漏调 = 死锁 - 相比
std::condition_variable + std::mutex手动实现，latch更轻量、无锁路径优化更好，且语义更清晰
std::latch l{2};
std::thread t1([&l]{ do_work(); l.count_down(); });
std::thread t2([&l]{ do_work(); l.count_down(); });
<p>l.wait(); // 主线程等两个子任务都完成
t1.join(); t2.join();barrier 和 latch 在异常或提前退出时怎么保安全？
两者都不处理线程中途崩溃或异常退出。一旦有线程没走到 arrive_and_wait() 或 count_down() 就退出，剩余线程必然死锁。没有内置的“超时取消”或“自动恢复”机制。
- 必须确保每个路径（包括异常分支）都调用对应同步操作：建议用 RAII 包装，例如写个
barrier_arriver或latch_counter类，在析构里调用count_down() -
std::barrier::arrive()是非阻塞版本，返回一个std::barrier<T>::arrival_token，可用于延迟wait()，但极少用；日常应坚持用arrive_and_wait()简化逻辑 - 不要混用：比如用
latch做多轮同步，或用barrier替代一次性等待 —— 语义错位容易引发维护困惑和误用 - 它们都不涉及内存序控制，对共享数据的读写仍需额外同步（如
std::atomic或互斥量），barrier的回调里修改变量，其它线程在arrive_and_wait()返回后才能安全读
什么时候该选 barrier，什么时候选 latch？
看同步模式是否需要“重复使用”和“是否允许部分线程跳过”。简单记：要循环等齐用 barrier，只等一次完成用 latch。
立即学习“C++免费学习笔记（深入）”；
- 并行排序的每轮分区后同步 →
barrier - 主线程等待日志模块、网络模块、配置加载三个初始化完成 →
latch{3} - 一个线程负责收集多个异步任务结果，但只关心“是否全到”，不关心谁先谁后 →
latch更合适 - 多个工作线程协作处理分片数据，每轮迭代都要等彼此算完再合并 →
barrier，且可用回调做合并
实际项目里，latch 使用频率略高，因为很多初始化/启动/关闭流程天然是一次性的；而 barrier 更多出现在高性能计算或自定义并行算法中。两者底层都基于 futex 或类似内核原语，性能远优于手写条件变量，但用错场景反而更难调试。
