工作中，经常会碰到并发读写 map 而造成 panic 的情况，为什么在并发读写的时候，会 panic 呢？因为在并发读写的情况下，map 里的数据会被写乱，之后就是 Garbage in, garbage out，还不如直接 panic 了。

是什么

Go 语言原生 map 并不是线程安全的，对它进行并发读写操作的时候，需要加锁。而 sync.map 则是一种并发安全的 map，在 Go 1.9 引入。

最近遇到了一起依赖升级 + 异常数据引发的线上事故，教训惨痛，本文对此进行回故和总结。

背景

起因是我们使用的服务框架版本比较老，GC 次数的 metrics 打点一直为 0，咨询了相关同学后，决定升级框架。升级的过程中，出现了 use of internal package xxx not allowed 的报错，又咨询了一下相关同学后，尝试使用 go mod 解决。

最近在工作中碰到了 GC 的问题：项目中大量重复地创建许多对象，造成 GC 的工作量巨大，CPU 频繁掉底。准备使用 sync.Pool 来缓存对象，减轻 GC 的消耗。为了用起来更顺畅，我特地研究了一番，形成此文。本文从使用到源码解析，循序渐进，一一道来。

很多时候，当我们跟着源码去理解某种事物时，基本上可以认为是以时间顺序展开，这是编年体的逻辑。还有另一种逻辑，纪传体，它以人物为中心编排史事，使得读者更聚焦于某个人物。以一种新的视角，把所有的事情串连起来，令人大呼过瘾。今天我们试着以这样一种逻辑再看 g0。

回顾一下 Go 夜读第 78 期，关于调度器源码分析的内容。我们讲过，与主线程绑定的 M 对应的 g0 的主要作用是提供一个比一般 goroutine 要大的多栈（64K）供 runtime 代码执行。

去年开始写文章的第一篇就是关于 defer，名字比较文艺：《Golang 之轻松化解 defer 的温柔陷阱》，还被吐槽了。因为这篇文章，到《Go 夜读》讲了一期。不过当时纯粹是应用层面的，也还没有跳进 Go 源码这个大坑，文章看着比较清新，也没有大段的源码解析。

第一章

MySQL 的灵活性体现在很多方面，但其中最与众不同的特性是它的存储引擎架构：将查询处理以及其他系统任务和数据的存储/提取相分离。这种设计使得我们可以在使用时根据性能、特性，以及其他需求来选择数据存储的方式。