在Go语言的门口，许多朋友将能够精通3天，开始项目的5天，在线业务迭代，21天的调查和定位问题。
最常见的主要错误之一，是面试最喜欢的问题之一：
（读者的问题）
为什么地图和切片不支持GO语言的并发阅读和写作，即非线程安全，为什么不支持？
看到技巧后，我们将开始讨论如何使他们“敌人”支持并发阅读？
今天，我们的文章是合理的，了解其原因和后果，并学会一起学习GO语言。
我们使用多个Goroutine操作类型切片的变量，以查看结果将如何变化。
如下：
输出结果：
您会发现，无论执行多少次，每个输出的值都不相同，也就是说，添加了切片的值，并且发生覆盖范围。
因此，周期中的添加数与最终值不同。这种情况不会报告错误，这是一个隐藏的问题，具有高外观速率。
这样做的主要原因是程序逻辑本身有问题。同时，当阅读相同的索引位置时，它自然会产生覆盖范围。
它也用于MAP.重新贴上类型映射的变量。
如下：
输出结果：
好人，该程序直接运行以报告错误。以及由GO源代码调用方法引起的致命错误，也就是说，GO过程将被中断。
我不得不说，由复合地图引起的错误提示。我有一个朋友，他看过几次，说了数十次，不同的群体，不同的人...
这是Nikkei的隐藏问题。
实际上，我们仍然具有同时阅读和写作地图（程序逻辑决定）的吸引力，因为GO语言的Goroutine太方便了。
例如，在编写爬行者任务时，基本上使用了多个Goroutine，并且在获得数据后，将其写入地图或切片中。
AU中的Go Maps提供了一种简单便捷的实现方法::
该语句声明一个变量，该变量是一个匿名结构，其中包含本机和嵌入式读写锁。
如果要从变量中读取数据，请调用读取锁：
要在变量中写入数据，请调用写作锁：
这是支持并发阅读和写作的最常见方法。
尽管前言具有MAP+MUTEX的极简主义方案，但仍然存在某些问题。也就是说，当地图的数据量非常大时，只有一个锁（Mutex）非常可怕。锁会导致大量冲突和低性能。
通用的解决方案正在碎片，将大图分为多个间隔，并且在每个间隔中使用多个锁，因此锁的粒径大大降低了。，GO团队没有建议进行比较，但已经采用了其他解决方案。
该计划得到GO1.9的支持，其支持并发阅读地图起着补充作用。
特别介绍了GO语言和阅读和写作图的支持，该图采用了“空间更改时间”机制。减少了两个数据结构，即：阅读和肮脏以减少锁对性能的影响：
它是专门为现场设计的，适合阅读更多。这是他的优势之一。
如果有许多写作/并发的场景，它将导致读取地图缓存失败，需要锁定，冲突变得更多，并且绩效急剧下降。这是他的主要劣势。
提供以下常用方法：
实际操作示例如下：
输出结果：
如果切成薄片，则主要是为问题索引。这无需纠结。它一定会在写作逻辑中有明显的缺陷，只需自己更改它即可。
但是Go Map不一样。许多人认为默认情况下会得到支持。为什么官方的官方官员仍得到支持？它太复杂了，性能太差了。为什么？
原因如下（通过@GO常见问题）：
总而言之，经过长时间的讨论，Go Map认为，GO MAP应该更适合典型的用法场景，而不是一小部分，这导致了大多数程序的成本（性能），这决定了不支持。
在今天的文章中，我们介绍了地图的基本介绍，并以GO语言进行了切片，并模拟了不支持并发读者的场景。
同时，它还讲述了行业中的共同支持，阅读和写作方法。最后，出于不合适的原因的原因使我们对整个原因和后果有了完整的了解。
我不知道您是否遇到了日常生活中GO语言中非线性安全性的问题。欢迎在评论区域留言与所有人交流！
如果您有任何疑问，请欢迎评论领域的反馈和交流，最好的关系是相互实现。对您的称赞是制造炸鱼的最大动力。感谢您的支持。
作者：炸鱼Eddycjy。文章不断更新，您可以搜索[大脑以炸鱼]阅读。本文github：github.com/eddycjy/blog已包括在内。