以Go的map是否并发安全为例，介绍最权威的Go语言资料的使用方法

公众号原文地址：https://mp.weixin.qq.com/s/KmT-Mu4YQDeaQY_95waj-Q

本篇目录

本篇目录
说明
正确使用正确的资料
最权威的 Go 语言资料是？
Go 语言的 map 是否是并发安全的？
扩大搜索范围
找到答案不等于结束
为什么要执着于一手资料？
参考

说明

相比于细节，更在意知识框架的构建和完善，因此有时候对一些技术细节不是很清楚，只是知道如何找答案。最近要认真编码，需要仔细考虑、敲定细节，趁此机会将 Go 语言的知识整理一下。

正确使用正确的资料

找到正确的资料、能够正确的使用、正确的理解，是最关键的一步。除非是初学者，否则不要使用二手、三手和倒了无数手的资料，长期来看使用非一手资料，就是在浪费时间和引入错误。第一手的资料常常晦涩难懂，需要经过长时间的积累和沉淀，才能比较熟练的运用，刚开始的时候可以用二手、三手的资料帮助理解，但一定要逼迫自己在一手资料中找到解答，这个过程会极大地提升认知。

下面以Go 语言的 map 是否是并发安全的？为例，演示一下 Go 语言的一手资料的用法。

最权威的 Go 语言资料是？

最权威的 Go 语言资料是什么？Go 官网上的语言规范：The Go Programming Language Specification](https://upload-images.jianshu.io/upload_images/9231674-be49b617a53a68f0?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)

这份资料可以理解为 Go 语言的设计文档之一，用表达式的方式对 Go 语言语法做出了最精确的定义，对 Go 语言特性的介绍也是最全面的。掌握了这一份资料，基本就掌握了 100% 的 Go 语言语法和大部分使用时应注意的细节。如果要了解 Go 语言的实现和一些更复杂的内容，需要去查阅其它文档。

Go Spec 不容易看懂，里面的每一个英文单词都认识，但是联在一起就看不明白了。因为这份文档是在从更高的维度描述 Go 语言，使用的是「编程入门」类书籍中没有的术语，譬如Lexical elements、Assignability，就好像把「桌子」称为「一种用木材制作而成的家具」一样。习惯了这种表达方式，并知道常见「称呼」的含义后，会发现从这份文档中找答案的效率非常高！

Go 语言的 map 是否是并发安全的？

先到 Go Spec 的 map 章节中阅读 map 的细节：

image

map 是这样定义的：

A map is an unordered group of elements of one type, called the element type,indexed by a set of unique keys of another type, called the key type.MapType     = "map" "[" KeyType "]" ElementType .KeyType     = Type .

从这一章里得知:

map 的 key 必须是可比（!=、==）的，不能是 function、map、slice，如果是接口类型，实际用到的值要可比；
没有初始化的 map 变量的值是 nil，空 map 要用内置的 make 函数创建，未初始化的 map 不等于 空的map；
map 的 size 是无限制的，用 make 函数创建 map 时，设置的 capacity 不会限制 map 的 size，map 的容量是随着 element 的插入动态增长的；

遗憾的是，在这里没有找到对并发操作的说明，用 golang.org 的站内搜索也没找到相关的信息。

扩大搜索范围

这时候用 Google 搜到了 stackoverflow 上的一篇问答：How safe are Golang maps for concurrent Read/Write operations?，引起注意的是这篇问答中的两个链接：

Go maps in action
Go 1.6 Release Notes: Runtime

第一个连接是 Go 官方博客的一篇文章，第二个连接是 Go 1.6 的 Release Notes，然后又从第一个连接中找到了一个 Go 问答：

Why are map operations not defined to be atomic?

把这个网页下拉到顶部，发现了一个宝藏，Frequently Asked Questions (FAQ)：

image

从上面几个链接中的内容得知，Go 的 map 不是并发安全的，这是设计人员经过长期讨论做出的决定：因为大部分使用 map 的场景不需要并发读写，如果将 map 设计为并发安全的，将降低大多数程序的性能。

只有在更新 map 的时候，map 才是并发不安全的，全部是读操作的并发是安全的。Go 1.6 对 map 的并发读写进行了更明确的规定：当一个协程正在对 map 进行写操作的时候，不能有其它协程在对同一个 map 进行操作，读和写都不行。Go 的 runtime 会对 map 的并发读写进行监测，如果发现不安全的操作直接 crash。