本文转载自微信公众号《我的脑子是炸鱼》，作者陈建宇。转载本文请联系脑筋急转弯公众号。大家好，我是炸鱼。初入Go语言，很多小伙伴3天快速掌握Go，5天上手项目，14天上线业务迭代，21天排查定位问题，并带来反思报告道路。最常见的初级错误之一，也是Go面试中最常被问到的问题之一：为什么在Go语言中，map和slice不支持并发读写，也就是非线性安全，为什么不支持呢？那么我们就要开始讨论如何让他们两个“冤家”支持并发读写了？今天我们就来探讨这篇文章，了解前因后果，一起学习理解Go语言。非线性安全示例slice我们使用多个goroutine对slice类型的变量进行操作，看结果如何变化。如下：funcmain(){vars[]stringfori:=0;i<9999;i++{gofunc(){s=append(s,"脑子炸了")}()}fmt.Printf("进入%donlyfriedfish",len(s))}outputresult://第一次执行时输入了5790条炸鱼//第二次执行时输入了7370条炸鱼//第三次执行时输入了6792条炸鱼Fish,you会发现无论执行多少次，每次输出的值很可能都不一样。也就是说，添加到切片的值被覆盖。因此，循环中添加的数字不等于最终值。而且这种情况下不会报错，属于隐性问题，发生率很低。这主要是程序逻辑本身有问题，同时读取同一个索引位时，自然会发生覆盖。地图也为地图做同样的事情。重复写入映射类型的变量。如下：funcmain(){s:=make(map[string]string)fori:=0;i<99;i++{gofunc(){s["炸鱼"]="吸鱼"}()}fmt.printf("Entered%dfriedfish",len(s))}输出结果：fatalerror:concurrentmapwritesgoroutine18[running]:runtime.throw(0x10cb861,0x15)/usr/local/Cellar/go/1.16.2/libexec/src/runtime/panic.go:1117+0x72fp=0xc00002e738sp=0xc00002e708pc=0x1032472runtime.maassign_faststr(0x10b3360,0xc0000a2180,0x10c91da,0x6,0x0)/usr/local/Cellgo.rungo/str_map1.c/2:211+0x3f1fp=0xc00002e7a0sp=0xc00002e738pc=0x1011a71main.main.func1(0xc0000a2180)/Users/eddycjy/go-application/awesomeProject/main.go:9+0x4cfp=0xc00002e7d8sp=0xc00002e7a0pc=0x10a474cruntime.goexit()/usr/local/Cellar/go/1.16.2/libexec/src/runtime/asm_amd64.s:1371+0x1fp=0xc00002e7e0sp=0xc00002e7d8pc=0x1063fe1createdbymain.main/Users/eddycjy/go-application/awesomeProject/main.go:8+0x55好家伙，程序运行起来会直接报错。并且是Go源码调用throw方法导致的致命错误，也就是说Go进程会被中断。不得不说致命错误：concurrentmapwritesconcurrentlywritethemap导致的错误信息。我有个朋友看过几十遍了，不同的群体，不同的人。。。是日经隐含的问题。如何支持并发读写锁定map其实我们还是有并发读写map的诉求的（由程序逻辑决定），因为Go语言中的goroutine实在是太方便了。比如写爬虫任务，基本都是用多个goroutine，拿到数据后，写成map或者slice。Go官方在Gomapsinaction中提供了一种简单方便的实现方式：varcounter=struct{sync.RWMutexmmap[string]int}{m:make(map[string]int)}这个语句声明了一个变量，它是一个匿名结构（struct）体，包含一个本机和一个嵌入式读写锁sync.RWMutex。从变量中读取数据，调用读锁：counter.RLock()n:=counter.m["friedfish"]counter.RUnlock()fmt.Println("friedfish:",n)来写入数据对一个变量，调用写锁：counter.Lock()counter.m["friedfish"]++counter.Unlock()这是Map支持并发读写最常见的方式。sync.MapPreface虽然有Map+Mutex的极简方案，但是还是存在一些问题。也就是当map的数据量非常大的时候，只有一把锁（Mutex）是很吓人的。一把锁会造成很多锁的争用，导致各种冲突，性能很差。一个常见的解决方案是分片，将一个大的map分成多个区间，每个区间使用多把锁，这样子锁的粒度就大大降低了。然而，该解决方案实施起来复杂并且容易出错。因此，Go团队至今没有推荐，而是采用了其他方案。本方案为Go1.9支持的sync.Map，支持并发读写map，起到补充作用。具体介绍Go语言的sync.Map，支持并发读写map。它采用“空间换时间”机制和冗余的两种数据结构，即：read和dirty，减少加锁对性能的影响：typeMapstruct{muMutexreadatomic.Value//readOnlydirtymap[interface{}]*entrymissesint}是专门设计的适用于append-only场景，即适用于读多写少的场景。这是他的强项之一。如果写/并发场景很多，读map缓存会失效，需要加锁，会产生更多的冲突，性能会急剧下降。这是他的主要缺点。提供了以下常用方法：func(m*Map)Delete(keyinterface{})func(m*Map)Load(keyinterface{})(valueinterface{},okbool)func(m*Map)LoadAndDelete(keyinterface{})(valueinterface{},loadedbool)func(m*Map)LoadOrStore(key,valueinterface{})(actualinterface{},loadedbool)func(m*Map)Range(ffunc(key,valueinterface{})bool)func(m*Map)Store(key,valueinterface{})Delete：删除一个key的值。Load：返回存储在map中的key的值，如果没有值则返回nil。ok结果指示是否在映射中找到该值。LoadAndDelete：删除键的值，如果有则返回以前的值。LoadOrStore：返回键的现有值（如果存在）。否则，它存储并返回给定的值。如果加载了值，则加载结果为真，如果已存储，则为假。Range：递归调用，依次为映射中存在的每个键和值调用闭包函数f。如果f返回false，则停止迭代。存储：存储和设置键的值。实际操作示例如下：varmsync.Mapfuncmain(){//写入数据:=[]string{"炸鱼","咸鱼","烤鱼","清蒸鱼"}fori:=0;i<4;i++{gofunc(iint){m.Store(i,data[i])}(i)}time.Sleep(time.Second)//读取v,ok:=m.Load(0)fmt.printf("Load:%v,%v\n",v,ok)//删除m.Delete(1)//读或写v,ok=m.LoadOrStore(1,"suckfish")fmt.Printf("LoadOrStore:%v,%v\n",v,ok)//遍历m.Range(func(key,valueinterface{})bool{fmt.Printf("Range:%v,%v\n",key,value)returntrue})}输出结果：Load:friedfish,trueLoadOrStore:suckedfish,falseRange:0,friedfishRange:1,suckedfishRange:3,steamedfishRange:2,为什么不支持烤鱼GoSlice，主要问题是索引位的覆盖，所以这个不用担心。肯定是编程逻辑有明显的缺陷，自己改正就好了。但是Go地图不同。很多人认为它是默认支持的，一不小心翻车就是这么常见。那么为什么Go官方不支持它呢？是不是太复杂，性能太差？为什么？原因如下（via@gofaq）：典型使用场景：map的典型使用场景是不需要从多个goroutine中访问。用于安全访问。非典型场景（需要原子操作）：地图可能是一些更大的数据结构的一部分或已经同步的计算。性能场景考虑：如果只增加少数几个程序的安全性，导致所有map操作都处理mutex会降低大部分程序的性能。综上所述，经过长时间的讨论，Go官方认为Gomap应该更适合典型的使用场景，而不是针对少数情况，导致大部分程序付出代价（性能），决定不支持。小结在今天的文章中，我们对Go语言中的map和slice做了一个基本的介绍，同时也模拟了一个不支持并发读取的场景。同时也介绍了目前业界常见的支持并发读写的方式，最后分析了不支持的原因，让大家对整个前因后果有了一个完整的认识。
