Go 为什么不在语言层面支持 map 并发？

很多小伙伴学习 Go 语言的语法时，可能只是轻轻地看到过这个问题，结果一旦上手，多多少少一个组内总会碰到过几次（我经常见到...）。

甚至会发现有一定年限的程序员也会遇到。有小伙伴疑惑了，这么折腾，为什么 Go 不直接在语言层面就支持 map 并发，直接无脑用。

那得有多香？

为什么原生不支持

凭什么 Go 官方还不支持，难不成太复杂了，性能太差了，到底是为什么？

官方答复原因如下（via @go faq）：

• 典型使用场景：map 的典型使用场景是不需要从多个 goroutine 中进行安全访问。

• 非典型场景（需要原子操作）：map 可能是一些更大的数据结构或已经同步的计算的一部分。

• 性能场景考虑：若是只是为少数程序增加安全性，导致 map 所有的操作都要处理 mutex，将会降低大多数程序的性能。

核心来讲就是：Go 团队在经过了长时间的讨论后，认为原生 map 更应适配典型使用场景。

如果为了小部分情况，将会导致大部分程序付出性能代价，决定了不支持原生的并发 map 读写。且在 Go1.6 起，增加了检测机制，并发的话会导致异常。

为什么要崩溃

前面有提到一点，在 Go1.6 起会进行原生 map 的并发检测，这是一些人的 “噩梦”。

在此有人吐槽到：“明明给我抛个错就好了，凭什么要让我的 Go 进程直接崩溃掉，分分钟给我背个 P0”。

场景枚举

这里我们假设一下，如果并发读写 map 是以下两种场景：

1. 产生 panic：程序 panic -> 默认走进 recover -> 没有对并发 map 进行处理 -> map 存在脏数据 -> 程序使用脏数据 -> 产生**未知((影响。

2. 产生 crash：程序 crash -> 直接崩溃 -> 保全数据（数据正常）-> 产生**明确((风险。

你会选择哪一种方案呢？Go 官方在两者的风险衡量中选择了第二种。

无论是编程，还是人生。如何在随机性中掌握确定性的部分，也是一门极大的哲学了。

let it crash

Go 官方团队选择的方式是业内经典的 “let it crash” 行为，很多编程语言中，都会将其奉行为设计哲学。

let it crash 是指工程师不必过分担心未知的错误，而去进行面面俱到的防御性编码。

这块理念最经典的就是 erlang 了。

总结

在今天这篇文章中，我们介绍了 Go 语言为什么不支持原生支持 map 并发，核心原因是大部分场景都不需要，从性能考虑上做的考虑。

直接让并发读写 map 的原因，是从 “let it crash” 去考虑。这块如果你想在自己的工程中避免这个情况，可以在 linter 等工具链加入竞态检测（-race），也可以避免这类风险。

你觉得 Go 这块的设计考虑怎么样呢？欢迎在评论区留言和交流：）

推荐阅读：

如果 map 不是引用变量，那是什么？

对了，看完文章，记得点击下方的卡片。关注我哦~ 👇👇👇

如果您的朋友也在学习 Go 语言，相信这篇文章对 TA 有帮助，欢迎转发分享给 TA，非常感谢！