大家好，我是煎鱼。
很多小伙伴学习 Go 语言的语法时，可能只是轻轻地看到过这个问题，后果一旦上手，多多少少一个组内总会碰到过几次。
甚至会发现有肯定年限的程序员也会遇到。有小伙伴纳闷了，这么折腾，为什么 Go 不间接在语言层面就反对 map 并发，那得有多香？
为什么原生不反对
凭什么 Go 官网还不反对，难不成太简单了，性能太差了，到底是为什么？
官网回答起因如下（via @go faq）：
- 典型应用场景：map 的典型应用场景是不须要从多个 goroutine 中进行平安拜访。
- 非典型场景（须要原子操作）：map 可能是一些更大的数据结构或曾经同步的计算的一部分。
- 性能场景思考：若是只是为多数程序减少安全性，导致 map 所有的操作都要解决 mutex，将会升高大多数程序的性能。
外围来讲就是：Go 团队在通过了长时间的探讨后，认为原生 map 更应适配典型应用场景。
如果为了小局部状况，将会导致大部分程序付出性能代价，决定了不反对原生的并发 map 读写。且在 Go1.6 起，减少了检测机制，并发的话会导致异样。
为什么要解体
后面有提到一点，在 Go1.6 起会进行原生 map 的并发检测，这是一些人的 “噩梦”。
在此有人吐槽到：“明明给我抛个错就好了，凭什么要让我的 Go 过程间接解体掉，分分钟给我背个 P0”。
场景枚举
这里咱们假如一下，如果并发读写 map 是以下两种场景：
- 产生 panic：程序 panic -> 默认走进 recover -> 没有对并发 map 进行解决 -> map 存在脏数据 -> 程序应用脏数据 -> 产生**未知((影响。
- 产生 crash：程序 crash -> 间接解体 -> 顾全数据（数据失常）-> 产生**明确((危险。
你会抉择哪一种计划呢？Go 官网在两者的危险掂量中抉择了第二种。
无论是编程，还是人生。如何在随机性中把握确定性的局部，也是一门极大的哲学了。
let it crash
Go 官网团队抉择的形式是业内经典的 “let it crash” 行为，很多编程语言中，都会将其奉行为设计哲学。
let it crash 是指工程师不用过分放心未知的谬误，而去进行八面玲珑的防御性编码。
这块理念最经典的就是 erlang 了。
总结
在明天这篇文章中，咱们介绍了 Go 语言为什么不反对原生反对 map 并发，外围起因是大部分场景都不须要，从性能思考上做的思考。
间接让并发读写 map 的起因，是从 “let it crash” 去思考。这块如果你想在本人的工程中防止这个状况，能够在 linter 等工具链退出竞态检测（-race），也能够防止这类危险。
你感觉 Go 这块的设计思考怎么样呢？欢送在评论区留言和交换：）
若有任何疑难欢送评论区反馈和交换，最好的关系是相互成就，各位的点赞就是煎鱼创作的最大能源，感激反对。
文章继续更新，能够微信搜【脑子进煎鱼了】浏览，本文 GitHub github.com/eddycjy/blog 已收录，学习 Go 语言能够看 Go 学习地图和路线，欢送 Star 催更。
转载请注明原文链接：Go-为什么不在语言层面支持-map-并发
