std::barrier为何会进行堆内存分配而std::latch不会？

你提到的可复用性确实是核心差异的源头，但直接导致堆分配的不是“可复用”这个特性本身，是可复用设计附带的两个实现层面的硬性要求，而std::latch作为一次性组件完全没有这些负担：

• 首先是状态尺寸的确定性差异
  std::latch的全部运行时状态只有一个原子计数器，外加对应的阻塞唤醒标记，所有尺寸在编译期完全固定，可以直接内联存储在std::latch对象自身的内存里，不需要额外申请空间。它的阻塞逻辑也非常简单：所有等待线程只需要等计数器降到0，直接依托futex等原语等待原子变量的地址即可，内核会维护等待队列，用户态不需要额外存储队列结构，计数器到0后对象生命周期基本走到终点，没有后续逻辑。
  而std::barrier支持自定义每轮同步完成后的回调函数（也就是构造时传入的CompletionFunction），这个回调可以是任意可调用对象——可能是没有捕获的lambda，也可能是捕获了大量变量的大尺寸函数对象。主流标准库实现（libstdc++、libc++等）都采用类型擦除的方式封装这个回调，避免因为用户传入的回调尺寸不确定导致std::barrier对象本身的大小不可控，这部分类型擦除的状态本身就需要动态存储。
• 其次是多阶段同步的ABA问题规避需求
  std::barrier是多轮复用的：第一轮所有线程到达屏障、执行完成回调后，计数器会重置为初始值，立刻进入下一轮同步。如果像latch一样直接futex等待同一个原子计数器，会出现严重的ABA问题：第一轮计数器刚重置为初始值，还没来得及唤醒第一轮等待的线程，这些线程就会因为计数器值变化被错误唤醒，逻辑直接错乱。
  为了解决这个问题，barrier必须单独维护每一轮的阶段标记、和阶段绑定的等待队列状态。主流实现普遍采用堆上动态分配的阶段控制块来做轮转：每一轮同步对应一个独立的控制块，线程只等待当前轮次控制块的标记，轮次切换时直接切换控制块指针即可，既不需要拷贝大量状态，也能从根本上规避ABA问题。

补充说明：C++标准从来没规定std::barrier必须走堆分配，只是目前所有主流标准库实现都选了这个方案——本质是平衡实现复杂度、运行性能、对象体积之后的工程选择。就算你给barrier传一个无捕获的空lambda当完成回调，大部分实现也不会专门开分支省掉这步分配，毕竟分支预测失败的开销，很多时候比一次小块堆分配还大。

内容的提问来源于stack exchange，提问作者Simon Gauvin