当前位置：首页 > news >正文

golang不使用锁的情况下，对slice执行并发写操作，是否会有并发问题呢？

news 来源：原创 2025/5/6 13:10:48

背景

并发问题最简单的解决方案加个锁，但是，加锁就会有资源争用，提高并发能力其中的一个优化方向就是减少锁的使用。

我在之前的这篇文章《开启多个协程，并行对struct中的每个元素操作，是否会引起并发问题？》中讨论过多协程场景下struct的并发问题。

Go语言中的slice在并发环境下并不是安全的。当多个goroutine同时对一个slice进行修改（如append操作）时，会导致数据竞争（data race），进而引发不可预测的结果，例如数据丢失、覆盖或程序崩溃。

那么，在什么情况下，可以不使用锁，也不会导致并发问题呢？

不使用锁触发并发案例

案例一：高并发下触发slice并发竞争问题

package main

import (
	"fmt"
	"sync"
)

func main() {
	var wg sync.WaitGroup
	slice := make([]int, 0)
	for i := 0; i < 100000; i++ {
		wg.Add(1)
		go func(j int) {
			defer wg.Done()
			slice = append(slice, j)
		}(i)
	}
	wg.Wait()
	fmt.Println("理论长度100000,实际长度:", len(slice))
}

通过提高并发数，触发并发问题暴露。执行的效果，实际的长度小于理论的长度，则证明一定因为并发导致了数据丢失，覆盖等并发问题。我们可以看一下实际执行的效果。

PS D:\Go\src\tool\concurrent> go run main.go
理论长度1000,实际长度: 88004
PS D:\Go\src\tool\concurrent> go run main.go
理论长度1000,实际长度: 88065
PS D:\Go\src\tool\concurrent> go run main.go
理论长度100000,实际长度: 89078
PS D:\Go\src\tool\concurrent> go run main.go
理论长度100000,实际长度: 88239

权威验证方法

使用Go内置的竞争检测器验证：

go run -race main.go

无论输出是否正常，该命令会直接告知代码中数据竞争的位置。

==================
WARNING: DATA RACE
Read at 0x00c000008048 by goroutine 8:
  main.main.func1()
      D:/Go/src/tool/concurrent/main.go:16 +0xb9
  main.main.func2()
      D:/Go/src/tool/concurrent/main.go:17 +0x41

Previous write at 0x00c000008048 by gorouti