并发问题概览
问题类型 | 描述 |
---|---|
数据竞争 | 多个协程对共享变量进行非同步读写操作 |
死锁 | 多个协程互相等待对方释放资源 |
活锁 | 协程不断尝试获取资源但始终失败 |
协程泄漏 | 协程未能及时退出,程序中 goroutine 数量飙升 |
Channel 误用 | 通道未关闭、重复关闭、关闭后写入等问题 |
调度抖动 | 非预期的调度行为导致响应不稳定 |
数据竞争
当两个或多个 goroutine 同时读写一个变量,并且至少有一个是写操作,而又没有同步措施时,就会发生数据竞争。
var count int
func 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() {
<-ch1
ch2 <- 1
}()
go func() {
<-ch2
ch1 <- 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] = i
mu.Unlock()
}(i)
}
time.Sleep(1 * time.Second)
fmt.Println("done")
}
var data sync.Map
func 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 int64
func worker(wg *sync.WaitGroup) {
defer wg.Done()
// 原子加1,确保并发安全
atomic.AddInt64(&globalCounter, 1)
}
func main() {
var wg sync.WaitGroup
wg.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.Mutex
func main() {
mu.Lock()
counter++
mu.UnLock()
}
- 使用 Channel 实现计数。性能不如原子操作,适用于有通道通信需求的场景。
var counter = make(chan int, 1)
func init() {
counter <- 0
}
func main() {
v := <-counter
v++
counter <- v
}