std::latch不能用于“等待全部线程准备就绪”，因其仅支持一次性向下计数和等待，缺乏就绪通知与状态重置能力，本质是完成同步而非就绪同步，应使用std::barrier。
std::latch 为什么不能用于“等待全部线程准备就绪”这个场景
std::latch 是一次性同步原语，只支持向下计数（count_down()）和阻塞等待（wait()），**没有“就绪通知”或“状态重置”能力**。它适合“等 N 个任务完成”，但不适合“等 N 个线程全部到达某个准备点”——因为后者需要每个线程主动声明“我好了”，且主线程要等齐所有声明才继续，这本质是**屏障（barrier）语义**，不是 latch 语义。
应该用 std::barrier 替代，且注意构造方式
C++20 提供了 std::barrier，专为“多线程汇合到同一逻辑点”设计。关键在初始化时传入预期线程数，并在每个线程里调用 arrive_and_wait()：
std::barrier sync_point{num_threads};
// 每个线程中：
sync_point.arrive_and_wait(); // 阻塞直到所有 num_threads 个线程都调用过
注意：std::barrier 构造时的参数是「参与汇合的线程总数」，不是剩余数；它内部自动管理状态，无需手动计数。
- 如果线程数在运行时确定（比如从 vector 启动），必须提前算好总数再构造
barrier，不能边启边加 -
arrive_and_wait()是带等待的汇合；若只需通知不等待，可用arrive()，但此时需另配机制通知主线程 -
std::barrier不可重用（C++20 初始版本），每次汇合后需重建；C++23 引入了std::flex_barrier支持回调和重入
常见误用：用 latch 模拟 barrier 导致死锁或提前唤醒
有人试图用 std::latch 实现准备就绪等待，比如主线程构造 latch{num_threads}，各工作线程启动后立刻 latch.count_down()，然后主线程 latch.wait()。这看似可行，但问题明显：
立即学习“C++免费学习笔记（深入）”；
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
- 工作线程可能还没真正“准备就绪”（比如资源未初始化完）就已调用
count_down()，导致主线程误判并提前继续 - 若某个线程崩溃或未执行
count_down()，latch.wait()永远阻塞 -
std::latch无超时接口（C++20），无法做兜底检测
换句话说，latch 只保证“N 次信号已发出”，不保证“N 个线程在指定位置同步停驻”。这是语义鸿沟，绕不开。
如果必须用 C++17 或更低版本怎么办
标准库无 barrier 时，可用 std::mutex + std::condition_variable 手写简易屏障，核心逻辑是：
int arrived = 0;
std::mutex mtx;
std::condition_variable cv;
// 每个线程：
{
std::unique_lock<std::mutex> lk(mtx);
++arrived;
if (arrived == expected_count) {
cv.notify_all();
} else {
cv.wait(lk, [&]{ return arrived == expected_count; });
}
}
但要注意：手写易出错，比如忘记 notify_all()、条件判断竞态、或 wait() 唤醒后未重新检查条件。生产环境建议直接升级到 C++20 并用 std::barrier。
真正难的不是写法，而是明确区分「完成同步」和「就绪同步」——前者用 latch，后者必须用 barrier 或等价机制。混淆这两者，代码表面能跑，实则埋着时序漏洞。
