Go 中多生产者/多消费者模式下的竞态与同步实践指南

碧海醫心

发布时间：2026-02-05 18:31:09

556人浏览过

来源于php中文网

原创

Go 中多生产者/多消费者模式下的竞态与同步实践指南

本文详解 go 语言中多生产者（20 goroutines）与多消费者（200 goroutines）共用共享状态（如全局计数器 `seq`）时的典型竞态问题，揭示为何看似“并发安全”的 channel 协调仍无法避免数据竞争，并提供基于 `atomic` 和 channel 的正确同步方案。

在 Go 的并发模型中，channel 是协调 goroutine 的核心机制，但它仅保证通信同步，不自动保护共享内存。你的原始代码中，requestChan 和 generatorChan 均为无缓冲 channel，这确实强制了生产者（generateStuff）与消费者（concurrentPrint）之间的请求-响应配对同步——即每个全局变量 seq 的非原子读写引发的数据竞争（data race）。

尽管 channel 协调了“谁来处理请求”，但一旦多个 generateStuff goroutine 同时从 requestChan 接收请求并执行 seq = seq + 1，就进入了临界区。由于该操作包含“读取 seq → 加 1 → 写回 seq”三步，且无任何互斥保护，在多核环境下（尤其启用 GOMAXPROCS > 1 时），极可能出现两个 goroutine 读到相同旧值、各自加 1 后写回，最终 seq 仅增加 1 而非 2——导致重复序号或跳号。即使当前输出看似有序，也仅是单核调度下的偶然现象，而非线程安全保证。

要彻底解决此问题，必须对共享状态 seq 的访问进行显式同步。推荐使用 sync/atomic 包提供的原子操作，它比 sync.Mutex 更轻量且无锁：

import "sync/atomic"

// 安全递增并返回新值
s := atomic.AddUint64(&seq, 1)

以下是重构后的健壮实现（已移除竞态、增强可读性与可观测性）：

ClipSketch AI

将视频瞬间转化为手绘故事

下载

package main

import (
    "log"
    "sync"
    "sync/atomic"
)

var seq uint64 = 0
var generatorChan = make(chan uint64, 10) // 可选：添加小缓冲提升吞吐
var requestChan = make(chan uint64, 10)

func generator(genID int) {
    for reqID := range requestChan {
        s := atomic.AddUint64(&seq, 1) // ✅ 原子递增，线程安全
        log.Printf("Gen:%2d ← Req:%3d | Seq:%d", genID, reqID, s)
        generatorChan <- s
    }
}

func worker(id int, work *sync.WaitGroup) {
    defer work.Done()
    for i := 0; i < 5; i++ {
        requestChan <- uint64(id)
        resp := <-generatorChan
        log.Printf("\tWorker:%3d → Seq:%4d", id, resp)
    }
}

func main() {
    log.SetFlags(log.Lmicroseconds | log.Lshortfile)

    const (
        numGen    = 20
        numWorker = 200
    )

    var wg sync.WaitGroup

    // 启动生产者
    for i := 0; i < numGen; i++ {
        go generator(i)
    }

    // 启动消费者
    wg.Add(numWorker)
    for i := 0; i < numWorker; i++ {
        go worker(i, &wg)
    }

    wg.Wait()
    close(requestChan) // 优雅关闭生产者
}

关键改进说明：