waitgroup 不能替代 barrier，因其仅计数不保证同步点；barrier 需用 sync.cond + sync.mutex 手写，核心是到达时递减计数并广播唤醒，且须注意重置与竞态。
Go sync.WaitGroup 不能当 Barrier 用
WaitGroup 是计数器，不是同步点。它只保证所有 goroutine 完成，但不保证它们“同时到达某一点”——这是 Barrier 的核心语义。想靠 wg.Add() + wg.Done() + wg.Wait() 实现类似 pthread_barrier_wait 的效果，会发现 goroutine 实际是串行汇合的：谁先调完 wg.Done()，谁就先从 wg.Wait() 返回，后续 goroutine 还在跑，根本没“齐步走”。
常见错误现象：time.Now() 打点显示各 goroutine 进入临界区时间差几十毫秒，远超预期；压测时吞吐量上不去，CPU 利用率却不高。
- Barrier 要求所有参与者阻塞直到全员就绪，而 WaitGroup 的
Wait()只是等待计数归零，不参与“就绪状态”的协调 - 没有内存屏障语义，编译器或 CPU 可能重排 Barrier 前后的读写，导致数据可见性问题
- 无法复位（reset），每次都要新建实例，不适合循环 barrier 场景
用 sync.Cond + sync.Mutex 手写 Barrier 更可控
标准库没提供 sync.Barrier，但用 sync.Cond 可以精确控制唤醒时机和顺序。关键在于：所有 goroutine 到达时先加锁、递减计数、判断是否全员到齐；是，则广播；否则等待。离开时无需额外同步，因为 Barrier 本身只管“到达”，不管“离开”。
示例逻辑：
立即学习“go语言免费学习笔记（深入）”；
type Barrier struct {
mu sync.Mutex
cond *sync.Cond
waiting int
total int
}
func (b *Barrier) Await() {
b.mu.Lock()
defer b.mu.Unlock()
b.waiting++
if b.waiting == b.total {
b.waiting = 0
b.cond.Broadcast()
} else {
b.cond.Wait()
}
}
-
b.cond.Wait()自动释放锁并挂起，被Broadcast()唤醒后重新持锁，避免竞态 - 必须用
if b.waiting == b.total而非for循环，因为 Broadcast 是一次性唤醒全部，不会虚假唤醒 - 注意
b.waiting = 0要在 Broadcast 前完成，否则新一批 goroutine 可能误判为“已满”
第三方库 github.com/arl/statsviz/v2 不含 Barrier，别被名字误导
搜索 “go barrier library” 常撞见 statsviz 或 go-concurrency 类项目，但它们专注可视化或 worker pool，没有实现标准 Barrier。真正可用的轻量级选择只有 github.com/cespare/xxhash/v2 这类无关库——等等，不对，那是哈希库。实际上，主流生态里稳定可用的 Barrier 实现极少，golang.org/x/sync/semaphore 是信号量，errgroup.Group 是错误传播，都不等价。
- 有人 fork
sync包手动加 Barrier，但 Go 团队明确表示不考虑加入（issue #39159），理由是使用场景太窄、易误用 - 若需高性能，避免在 hot path 上用 mutex+cond，可考虑基于
atomic.Int64的无锁轮询（但要处理 ABA 和忙等功耗） - Go 1.22+ 的
runtime_pollWait底层支持更细粒度调度，但上层 API 仍未暴露 Barrier 原语
Barrier Latency 主要来自调度延迟和锁争用
实测中，50 个 goroutine 的 Barrier 平均延迟常在 10–50μs，但 P99 可能跳到 2ms 以上。这不是 Barrier 实现慢，而是 Go runtime 调度器把 goroutine 分配到不同 M/P 上，唤醒后还要抢锁、上下文切换、cache line bouncing。
- 延迟敏感场景下，应限制 Barrier 规模（
total ），避免单次 Broadcast 唤醒过多 goroutine 导致 thundering herd - 不要在 Barrier 内做任何 I/O 或系统调用，否则 goroutine 会出队列，再次入队时调度延迟不可控
- 如果只是为“等一组计算结束再汇总”，用
errgroup.Group+ channel 更轻量；Barrier 真正必要，仅限需要严格时序对齐的场景（如分布式快照、多阶段流水线同步点）
Barrier 的麻烦不在写，而在判断“到底要不要它”。很多以为需要 Barrier 的地方，其实只是没理清数据依赖关系。一旦用了，就得为那几微秒的不确定性负责——它藏在调度器深处，没法 profile，也没法 patch。
