文章目录
目录
- 并发问题概览
- 最佳实践总结
- 实际案例分析
- 高并发下创建全局计数器
| 问题类型 | 描述 |
|---|---|
| 数据竞争 | 多个协程对共享变量进行非同步读写操作 |
| 死锁 | 多个协程互相等待对方释放资源 |
| 活锁 | 协程不断尝试获取资源但始终失败 |
| 协程泄漏 | 协程未能及时退出，程序中 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: %vn", 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
}
到此这篇关于Golang 并发的实现的文章就介绍到这了,更多相关Golang 并发内容请搜索风君子博客以前的文章或继续浏览下面的相关文章希望大家以后多多支持风君子博客！
您可能感兴趣的文章:
- Golang 并发读写锁的具体实现
- golang高并发之本地缓存详解
- Golang 并发控制模型的实现
- 详解Golang并发控制的三种方案
- golang实现并发控制的方法和技巧
- Golang中常见的三种并发控制方式使用小结
- Golang并发控制的三种实现方法