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
}