Go语言单线程运行也会有的并发问题解析

Go单线程多goroutine访问一个map会遇到并发读写panic么？

一个 Go 大佬群中严肃的讨论了一个问题：Go 程序单线程多 goroutine 访问一个 map 会遇到并发读写 panic 么？

答案是肯定的，因为出现了这个问题所以大家才在群中讨论。

为什么呢？因为单线程意味着并行单元只有一个(多线程也可能并行单元只有一个)，但是多 goroutine 意味着并发单元有多个，如果并发单元同时执行，即使是单线程，可能就会产生数据竞争的问题，除非这些 goroutine 是顺序执行的。

举一个例子哈：

func TestCounter() {
    runtime.GOMAXPROCS(1)
 var counter int
 var wg sync.WaitGroup
 wg.Add(10)
 for i := 0; i < 10; i++ {
  i := i
  go func() {
   fmt.Printf("start task#%d, counter: %d\n", i, counter)
   for j := 0; j < 10_0000; j++ {
    counter++
   }
   fmt.Printf("end task#%d, counter: %d\n", i, counter)
   wg.Done()
  }()
 }
 wg.Wait()
 fmt.Println(counter)
}

这段测试代码是启动 10 个 goroutine 对计数器加一，每个 goroutine 负责加 10 万次。在我的 MBP m1 笔记本上，每次的结果都是 100 万，符合期望。如果你运行这段代码，会发现 goroutine 其实是一个一个串行执行的(9->0->1->2->3->4->5->6->7->8，当然可能在你的机器上不是这样的)，如果是串行执行，不会有并发问题：

start task#9, counter: 0
end task#9, counter: 100000
start task#0, counter: 100000
end task#0, counter: 200000
start task#1, counter: 200000
end task#1, counter: 300000
start task#2, counter: 300000
end task#2, counter: 400000
start task#3, counter: 400000
end task#3, counter: 500000
start task#4, counter: 500000
end task#4, counter: 600000
start task#5, counter: 600000
end task#5, counter: 700000
start task#6, counter: 700000
end task#6, counter: 800000
start task#7, counter: 800000
end task#7, counter: 900000
start task#8, counter: 900000
end task#8, counter: 1000000
1000000

插入runtime.Gosched()

为了制造点紧张气氛，我将代码改写成下面这样子，将counter++三条指令明显写成三条语句，并在中间插入runtime.Gosched(),故意给其它 goroutine 的执行制造机会：

func TestCounter2() {
    runtime.GOMAXPROCS(1)
 var counter int
 var wg sync.WaitGroup
 wg.Add(10)
 for i := 0; i < 10; i++ {
  i := i
  go func() {
   fmt.Printf("start task#%d, counter: %d\n", i, counter)
   for j := 0; j < 10_0000; j++ {
    temp := counter
    runtime.Gosched()
    temp = temp + 1
    counter = temp
   }
   fmt.Printf("end task#%d, counter: %d\n", i, counter)
   wg.Done()
  }()
 }
 wg.Wait()
 fmt.Println(counter)
}

运行这段代码，你就会明显看到数据不一致的效果，即使是单个线程运行 goroutine,也出现了数据竞争的问题：

start task#9, counter: 0
start task#0, counter: 0
start task#1, counter: 0
start task#2, counter: 0
start task#3, counter: 0
start task#4, counter: 0
start task#5, counter: 0
start task#6, counter: 0
start task#7, counter: 0
start task#8, counter: 0
end task#9, counter: 100000
end task#1, counter: 100000
end task#3, counter: 100000
end task#2, counter: 100000
end task#5, counter: 100000
end task#0, counter: 100000
end task#4, counter: 100000
end task#6, counter: 100000
end task#7, counter: 100000
end task#8, counter: 100000
100000

这个结果非常离谱，期望 100 万，最后只有 10 万。

访问同一个 map对象也有可能出现并发bug

因为单个线程运行多个 goroutine 会有数据竞争的问题，所以访问同一个 map 对象也有可能出现并发 bug,比如下面的代码，10 个 goroutine 并发的写同一个 map:

func TestMap() {
 var m = make(map[int]int)
 var wg sync.WaitGroup
 wg.Add(10)
 for i := 0; i < 10; i++ {
  i := i
  go func() {
   fmt.Printf("start map task#%d, m: %v\n", i, len(m))
   for j := 0; j < 10_0000; j++ {
    m[j] = i*10_0000 + j
   }
   fmt.Printf("end map task#%d, m: %v\n", i, len(m))
   wg.Done()
  }()
 }
 wg.Wait()
}

大概率会出现 panic:

start map task#9, m: 0
start map task#0, m: 49152
fatal error: concurrent map writes
goroutine 41 [running]:
main.TestMap.func1()
 /Users/chaoyuepan/study/single_thread/main.go:72 +0xcc
created by main.TestMap in goroutine 1
 /Users/chaoyuepan/study/single_thread/main.go:69 +0x4c
goroutine 1 [semacquire]:
sync.runtime_Semacquire(0x140000021a0?)
 /usr/local/go/src/runtime/sema.go:62 +0x2c
sync.(*WaitGroup).Wait(0x1400000e1d0)
 /usr/local/go/src/sync/waitgroup.go:116 +0x74
main.TestMap()
 /Users/chaoyuepan/study/single_thread/main.go:79 +0xb8
main.main()
 /Users/chaoyuepan/study/single_thread/main.go:15 +0x2c

以上就是Go语言单线程运行的并发问题解析的详细内容，更多关于Go单线程运行并发问题的资料请关注脚本之家其它相关文章！

最新评论