今天说说go多协程并发访问map导致的fatal error

1.背景描述

最近写了一个批量查询的接口,因为泰慢,改用goroutine进行并发操作,代码是大概这样的

func foo(rsp Rsp){
	for _,i:=range rsp.Items {
		go func(){
			//一大堆业务操作,然后得到key跟value
			rsp.Map[key]=value
		}()
	}
}

结果这段代码在测试环境玩的好好的,上到生产就立刻崩了.

2.问题定位

在生产的机器中找到错误日志如下:

很明显的一个错误,是并发访问map异常.
在Java中,并发写map是可能导致死锁,好家伙,golang直接给你fatal error进程直接崩溃.二话不说根据提示看看为啥会崩

3.刨根问底

搜索了golang的一大堆源码解析文章,得知mapaccess1_fast64这个函数是map写key的函数,我们看看这个异常是怎么抛出来的,只看下面注解内容

func mapaccess1_fast64(t *maptype, h *hmap, key uint64) unsafe.Pointer {
	...
	if h.flags&hashWriting != 0 {
		throw("concurrent map read and map write")
	}
	...
}

就是这里,看来是 h.flags的状态位不为0,那么我们看下这个状态,还有这个掩码到底是啥意思,翻了了一下map的源码src/runtime/map.go,可以得到下面几个信息:

//h.flags:是map这个结构体自己的状态位

// A header for a Go map.
type hmap struct {
	flags     uint8
}

//hashWriting:是表示h.flags对应的二进制位的掩码
hashWriting  = 4 // a goroutine is writing to the map

OK,那么我们再来看看h.flags的 10 位上面是什么被改的

// Like mapaccess, but allocates a slot for the key if it is not present in the map.
func mapassign(t *maptype, h *hmap, key unsafe.Pointer) unsafe.Pointer {
	...
	// Set hashWriting after calling t.hasher, since t.hasher may panic,
	// in which case we have not actually done a write.
	h.flags ^= hashWriting
	...
}

可见这里,如果有一个goroutine进来的时候,就会把这个map的状态位置为1.
注意:因为协程,并不是多线程,所以这里对h.flags赋值时,只是可能会有并发问题.所以这就是为什么我在测试环境不会fatal error.而上去了就必现的原因.

4.解决方式

加锁呗,不想搞chan啥的泰复杂了,因为逻辑不重,所以解决了这个问题

func foo(rsp Rsp){
	var lock sync.Mutex
	for _,i:=range rsp.Items {
		go func(){
			//一大堆业务操作,然后得到key跟value
			lock.lock()
			rsp.Map[key]=value
			lock.Unlock()
		}()
	}
}