共计 1185 个字符，预计需要花费 3 分钟才能阅读完成。
大家好，我是煎鱼。
很多小伙伴学习 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 催更。