Golang 并发小结

并发问题概览

问题类型	描述
数据竞争	多个协程对共享变量进行非同步读写操作
死锁	多个协程互相等待对方释放资源
活锁	协程不断尝试获取资源但始终失败
协程泄漏	协程未能及时退出，程序中 goroutine 数量飙升
Channel 误用	通道未关闭、重复关闭、关闭后写入等问题
调度抖动	非预期的调度行为导致响应不稳定

数据竞争

当两个或多个 goroutine 同时读写一个变量，并且至少有一个是写操作，而又没有同步措施时，就会发生数据竞争。

var count intfunc add() {for i := 0; i< 1000; i++ {count++}
}func main() {go add()go add()time.Sleep(time.Second)fmt.Println(count)
}

死锁

死锁是指两个或多个协程相互等待，导致程序永久阻塞。

func main() {ch := make(chan int)// 没有其他协程接收，死锁ch <- 1
}

func main() {ch1 := make(chan int)ch2 := make(chan int)go func() {<-ch1ch2 <- 1}()go func() {<-ch2ch1 <- 1}()// 程序卡死time.Sleep(time.Second * 2)
}

协程泄漏

程序创建了大量 goroutine，但它们没有退出条件，一直处于阻塞或者等待状态，导致程序资源消耗飙升。

func main() {ch := make(chan int)for {go func() {// 不断产生阻塞的 goroutine，直到内存耗尽为止<-ch}()}
}

Channel 误用

// 写入已关闭通道
ch := make(chan int)
close(ch)
ch <- 1 // panic// 重复关闭通道
close(ch)
close(ch) // panic// 从空通道中读取，没有写入，造成死锁
<-ch

调度器问题与性能抖动

• 协程爆炸。短时间内创建了大量 goroutine，可能会导致 CPU 抖动、调度混乱。
• 大量阻塞系统调用。一个协程如果陷入系统调用阻塞，会被 OS 挂起，从而影响调度。
• 非公平调度。虽然 Go 的调度器基于 GMP 模型，但仍存在协程饥饿的可能。

最佳实践总结

类型	建议
数据共享	使用 Channel 或者 sync.Mutex/sync.RWMUtex 做同步
goroutine 控制	使用 WaitGroup 或者 context 管理协程生命周期
Channel 操作	所有写操作前确保通道未关闭；关闭通道应由发送方负责
并发任务分发	使用协程池（限制并发数）避免系统资源耗尽
调试工具	使用 race、pprof、trace、delve
日志分析	打印 goroutine ID，观察并发流程

实际案例分析

抓取系统协程泄漏

现象：

• CPU 使用率低
• 内存占用持续上涨
• goroutine 数量不断增长

分析：

• 使用 pprof 查看 goroutine 源码位置
• 定位原因是某个 select 分支缺少 <-done，导致协程无法退出

处理：

• 所有的 for + select 中都加上 ctx.Done() 处理退出

func worker() {go func() {for {select {case msg := <-someChan:// 处理消息fmt.Println(msg)// ❌ 没有退出条件，协程永远不会退出}}}()
}

func worker(ctx context.Context) {go func() {for {select {case msg := <-someChan:fmt.Println(msg)case <-ctx.Done():// ✅ 收到取消信号，退出协程fmt.Println("worker exiting")return}}}()
}ctx, cancel := context.WithCancel(context.Background())
worker(ctx)// 一段时间后或某个条件下，调用 cancel() 来通知协程退出
time.Sleep(5 * time.Second)
cancel()

异步任务竞争导致数据错乱

现象：

• 后台异步处理任务对全局 map 并发写入

分析：

• 偶发出现数据错误，调试困难

处理：

• 使用 sync.Mutex 或者 sync.Map

// 全局 map，非线程安全
var data = make(map[int]int)func main() {for i := 0; i < 100; i++ {go func(i int) {data[i] = i // 🚨 多个协程同时写入 map，会导致数据竞争或 panic}(i)}time.Sleep(1 * time.Second)fmt.Println("done")
}

var (data = make(map[int]int)mu   sync.Mutex
)func main() {for i := 0; i < 100; i++ {go func(i int) {mu.Lock()data[i] = imu.Unlock()}(i)}time.Sleep(1 * time.Second)fmt.Println("done")
}

var data sync.Mapfunc main() {for i := 0; i < 100; i++ {go func(i int) {data.Store(i, i)}(i)}time.Sleep(1 * time.Second)data.Range(func(k, v interface{}) bool {fmt.Printf("key: %v, value: %v\n", k, v)return true})
}

高并发下创建全局计数器

• 推荐使用 sync/atomic 包。sync/atomic 提供了原子操作的能力，在无需加锁的前提下，保证线程安全，适用于计数器等场景。

var globalCounter int64func worker(wg *sync.WaitGroup) {defer wg.Done()// 原子加1，确保并发安全atomic.AddInt64(&globalCounter, 1)
}func main() {var wg sync.WaitGroupwg.Add(1000)for i := 0; i < 1000; i++ {go worker(&wg)}// 确保主 goroutine 等待所有子 goroutine 完成wg.Wait()fmt.Println("计数器值：", globalCounter)
}

• 使用 sync.Mutex。线程安全但是性能略低，适用于复杂逻辑下的线程保护，不推荐用于简单加减场景。

var counter int
var mu sync.Mutexfunc main() {mu.Lock()counter++mu.UnLock()
}

• 使用 Channel 实现计数。性能不如原子操作，适用于有通道通信需求的场景。

var counter = make(chan int, 1)func init() {counter <- 0
}func main() {v := <-counterv++counter <- v
}