以假乱真的“人造脸”

这篇文档是会被经常编辑的，并且随着时间推移目前的内容可能会过时。这篇文档旨在说明写 runtime 代码和普通的 go 代码有什么不同，所以关注于一些普遍的概念而不是一些细节的实现。

调度器结构

调度器管理三个在 runtime 中十分重要的类型：G、M和P。哪怕你不写 scheduler 相关代码，你也应当要了解这些概念。

G、M 和 P

一个G就是一个 goroutine，在 runtime 中通过类型g来表示。当一个 goroutine 退出时，g对象会被放到一个空闲的g对象池中以用于后续的 goroutine 的使用(译者注：减少内存分配开销)。

一个M就是一个系统的线程，系统线程可以执行用户的 go 代码、runtime 代码、系统调用或者空闲等待。在 runtime 中通过类型m来表示。在同一时间，可能有任意数量的M，因为任意数量的M可能会阻塞在系统调用中。(译者注：当一个M执行阻塞的系统调用时，会将M和P解绑，并创建出一个新的M来执行P上的其它G。)

最后，一个P代表了执行用户 go 代码所需要的资源，比如调度器状态、内存分配器状态等。在 runtime 中通过类型p来表示。P的数量精确地(exactly)等于GOMAXPROCS。一个P可以被理解为是操作系统调度器中的 CPU，p类型可以被理解为是每个 CPU 的状态。在这里可以放一些需要高效共享但并不是针对每个P(Per P)或者每个M(Per M)的状态(译者注：意思是，可以放一些以P级别共享的数据)。

调度器的工作是将一个G(需要执行的代码)、一个M(代码执行的地方)和一个P(代码执行所需要的权限和资源)结合起来。当一个M停止执行用户代码的时候(比如进入阻塞的系统调用的时候)，就需要把它的P归还到空闲的P池中;为了继续执行用户的 go 代码(比如从阻塞的系统调用退出的时候)，就需要从空闲的P池中获取一个P。

所有的g、m和p对象都是分配在堆上且永不释放的，所以它们的内存使用是很稳定的。得益于此，runtime 可以在调度器实现中避免写屏障(译者注：垃圾回收时需要的一种屏障，会带来一些性能开销)。

用户栈和系统栈

每个存活着的(non-dead)G都会有一个相关联的用户栈，用户的代码就是在这个用户栈上执行的。用户栈一开始很小(比如 2K)，并且动态地生长或者收缩。

每一个M都有一个相关联的系统栈(也被称为g0栈，因为这个栈也是通过g实现的);如果是在 Unix 平台上，还会有一个 signal栈(也被称为gsignal栈)。系统栈和signal栈不能生长，但是足够大到运行任何 runtime 和 cgo 的代码(在纯 go 二进制中为 8K，在 cgo 情况下由系统分配)。

runtime 代码经常通过调用systemstack、mcall或者asmcgocall临时性的切换到系统栈去执行一些特殊的任务，比如：不能被抢占的、不应该扩张用户栈的和会切换用户 goroutine 的。在系统栈上运行的代码隐含了不可抢占的含义，同时垃圾回收器不会扫描系统栈。当一个M在系统栈上运行时，当前的用户栈是没有被运行的。

getg()和getg().m.curg

如果想要获取当前用户的g，需要使用getg().m.curg。

getg()虽然会返回当前的g，但是当正在系统栈或者signal栈上执行的时候，会返回的是当前M的g0或者gsignal，而这很可能不是你想要的。

如果要判断当前正在系统栈上执行还是用户栈上执行，可以使用getg() == getg().m.curg。
 

最近在研究性能优化的时候，看到了 golang runtime 包下的一个文档HACKING.md觉得颇有意思，读完之后觉得对于 runtime 的理解更上一层，于是想着翻译一下。

本章内容会有一定深度，需要有一定基础的读者，限于篇幅在这里不可能完全展开各个细节。

这一篇文档面向的读者是 runtime 的开发者，所以有很多内容在我们普通使用中是接触不到的。

（编辑：莆田站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!