std::latch不能用于等待“所有线程启动完毕”，因其仅支持单向计数且无法感知线程实际执行起点；应改用std::barrier，它通过arrive_and_wait()确保所有线程抵达同一同步点后再统一继续。
std::latch 为什么不能用于等待“所有线程启动完毕”
std::latch 是一个一次性同步原语，只支持 count_down() 和 wait()，它不提供“反向计数”或“等待被唤醒后再重置”的能力。关键点在于：它无法知道线程是否“已启动”，只能被动接收计数信号。而“线程启动完毕”这个状态本身没有原子定义——std::thread 构造函数返回 ≠ 线程函数首行代码执行完毕，中间存在调度延迟和内存可见性间隙。
常见误用是在线程函数开头立刻调用 latch.count_down()，但此时主线程可能还在构造 std::thread 对象、复制参数、分配栈，甚至还没开始调度该线程，latch.wait() 就提前返回了。
正确做法：用 std::barrier 替代 std::latch
std::barrier 是 C++20 引入的专为“多线程协同启动/阶段同步”设计的工具，它天然支持“所有参与者抵达后统一继续”，且每个线程调用 arrive_and_wait() 时会阻塞直到全部到达——这正好对应“等所有线程都执行到某一点（比如初始化完成）再一起往下走”。
-
std::barrier构造时指定参与线程数，无需手动管理计数逻辑 - 每个线程在关键同步点调用
barrier.arrive_and_wait()，安全阻塞并保证内存序 - 主线程不需要额外 sleep 或轮询，也不依赖线程对象是否“已运行”
- 比手写
std::mutex+std::condition_variable更轻量、无虚假唤醒风险
std::barrier barrier(4); // 期望 4 个线程共同抵达
for (int i = 0; i < 3; ++i) {
std::thread([&, i] {
// 模拟线程初始化工作
do_some_setup(i);
barrier.arrive_and_wait(); // 所有线程到这里才一起放行
run_main_logic(i);
}).detach();
}
// 主线程也参与同步（可选，取决于场景）
barrier.arrive_and_wait();
// 此时可确信所有线程已完成 setup 并开始 run_main_logic
如果必须用 std::latch，只能退化为“等待线程对象构造完成”
仅适用于极简单场景：你只关心“主线程已成功创建出 N 个 std::thread 对象”，不关心它们是否真正开始执行。这时可在构造后立即 count_down()：
立即学习“C++免费学习笔记（深入）”；
- 主线程每成功构造一个
std::thread，就对latch.count_down() - 然后主线程调用
latch.wait()—— 这只是等“构造动作完成”，不是等线程执行 - 该模式下，线程可能仍在内核队列中排队，
std::this_thread::yield()也无法保证调度顺序 - 若线程函数中有静态局部变量初始化，仍可能触发首次访问时的延迟，
latch完全无法覆盖这类行为
容易被忽略的内存序与初始化竞争
即使用了 std::barrier，如果线程间共享数据（比如全局配置、线程局部指针），仍需注意初始化时机：
- 所有线程的
do_some_setup()必须在barrier.arrive_and_wait()前完成对共享资源的初始化 - 避免在 barrier 后才首次访问未初始化的
static变量（C++11 静态局部变量初始化是线程安全的，但首次访问仍可能阻塞） -
barrier保证的是同步点的顺序，不自动保护数据；若 setup 中写入共享结构体，建议用std::atomic或加锁明确标注临界区
实际项目里，“所有线程启动完毕”往往是个模糊需求——你要的到底是“对象已存在”“入口函数已进入”还是“初始化逻辑已提交”？选错同步原语，后面所有假设都会偏移。
