豆浆大叔

本博的微信公众号，欢迎扫描订阅 >_<

约一年前，开了这个博客，原也想过微信公众号，不过也有点担心自己坚持不了，也不想给自己啥更新的压力，然后就没开了。

现在看来，保持得还不错，所以打算把微信公众号搞起来，估计每月一两篇的节奏，记录一些自己的学习心得之类的，欢迎关注。

写作的目的

为啥想写文章呢

1. 让自己的体会更深，更系统化
   工作中的学习，通常都是目的性比较强的，为了解决某个具体问题，了解个大概，知道怎么用，就也够用了。
   写文章呢，相对来说会更系统化一些，也会促使了解底层的原理机制。
   所以，写文章可以让自己有更好的沉淀，有更深的认识。

2. 好记性不如烂笔头
   有些知识当时记得挺清楚，过个一年半载就模糊了，把自己的文章翻出来看看，也是挺有用的，可以快速捡起来。

3. 期望得到一些正反馈
   自己的学习心得，总结成文，如果对他人也有些用处，可以得到一些认可，那也是很好的正反馈，可以大大提高写作动力。
   如果能有幸产生一些交流，纠正错误 / 加深理解，那就更美了，毕竟搞技术大多时候是孤独的，有人同道中人聊上几句是很难得的美事。

为啥微信公众号

去年一开始的时候，写的文章是发在思否，这种专业社区网站确实流量大，随便一篇文章都是上千的阅读。
如果赶上编辑能推荐上个首页，大几千的阅读也是有的。

不过，不是太喜欢这种模式，一是功利心变强，会比较多的分心去关注阅读量；二是平台的操纵感比较强，获得编辑推荐，阅读量就会更可观。
最后，感觉这些阅读量也没啥意义，虽然数字有几千，但是也没啥人留言互动，没啥意思，就只在自己的博客站上发了。

后来，在博客上写文章，自认为写得不错的，就分享到微信朋友圈，也有一些阅读量，朋友圈还能收到一些赞，感觉也挺好的了。

希望开了公众号之后，能减少在朋友圈的自我吆喝，能收获一些阅读/点赞，就挺好的了~

如果你对我的文章有兴趣，欢迎订阅，更欢迎交流，唠嗑~

旧印象

对于 c++，一直以来的感觉是，就像现在的邻居，明明经常能见到，还很熟一样的打打招呼，但是对他的底细却一点也不清楚，能看到他每天也去上班，连他干啥的也不清楚。

大学的入门编程语言是 c，虽也曾看过一点 c++ 的书，但是也不得要领，留下了一个 带类的 c 语言，这么个初步印象。

工作之后，写过一些 c 代码，对 c 还算得上有一些了解，还看过一些 c 和 c++ 的语言之争，留下一个 c++ 非常复杂，让人望而却步的印象。

缘起

近来要搞 Envoy，需要用到 c++，开始认真的学习 c++，目前有了一些体会，准备写几篇记录一下，加深下理解。

目前计划的有：

1. 智能指针，也就是本文
2. 变量引用
3. 并发冲突

一句话解释

智能指针就是，基于引用计数实现的，自动垃圾回收。

垃圾回收

现代语言的演进，有一个方向就是，降低使用者的心智负担，把复杂留给编译器。
其中，自动垃圾回收（GC)，就是其中一个进展良好的细分技术。

比如 c，作为一个 “古老” 的语言，提供了直接面向硬件资源的抽象，内存是要自己管理的，申请释放都完全由自己控制。

然，很多后辈语言，都开始提供了自动垃圾回收，比如，我之前用得比较用的 Lua，前一阵学的 go 语言，都是有 GC 加持的。
有了 GC 加持，确实很大程度的较低了程序员的心智负担，谁用谁知道。

既然效果这么好，那为什么不是每个语言都提供呢？

因为 GC 要实现好了，是挺复杂的。
想想 Java 的 GC 都演进了多少代了，多少牛人的聪明才智投入其中，没一定的复杂度，是对不起观众的。

在 GC 实现方式里，有两个主要方案：

标记清除

这个方案里，最简单的实现里，会将程序运行时，简单分为两种状态：

1. 正常执行代码逻辑状态，期间会申请各种需要的 GC 对象（内存块）
2. GC 状态，期间会扫描所有的 GC 对象，如果一个对象没有引用了，那就是 死 了，会被清除掉（释放）。

这个方案，有一个弊端，GC 状态的时候，正常的代码逻辑就没法跑了，处于世界停止的状态 STW。

虽然，有很多的优化手段，可以将这个 GC 状态，并发执行，或者将其打散，拆分为很多的小段，使得 STW 时间更多。
比如有 Go，Java 这种有多线程的，可以有并发的线程来执行 GC；Lua 这种单线程的，也会将标记拆分为分步执行。
甚至，Java 还有分代 GC 等优化技术，减少扫描标记的消耗。

但是，终于是有一些很难绕过去的点，GC 过程中还是需要一些 STW 来完成一些状态的同步。
且，GC 终究是一个较大的批处理任务，即使并发 + 打散，对于运行的程序而言，始终是一些 额外 的负担。

GC 对于实时在线提供服务的系统而言，就是不确定的突发任务来源，搞不好就来个波动，造成业务系统的突发毛刺。

引用计数

简单来说，每个 GC 对象，都有一个计数器，被引用的数量。

如下示例中，第一行，new Foo() 创建了一个对象，f 则是引用了这个对象，此时对象的引用技术器为 1。
当前作用域结束之后，f 作为局部变量，也到了生命的尽头，对象也少了这种引用，引用计数为 0。
如果有 GC 加持的话，这里新建的对象，也就会被自动释放了。

1
2
3
4

{
    Foo *f = new Foo();
    ...
}

引用计数器的变化，是混在正常的逻辑代码执行流中的，天然就是打散的。
引用计数，可以很好的解决上一个方案的问题。

只不过，引用计数有个致命的弱点，对于循环引用无解，所以，通常使用引用计数的语言，也会混合使用标记清除办法，解决循环引用的问题。

智能指针

c++ 提供了 share_ptr, unique_ptr 和 weak_ptr 这三种智能指针。

shared_ptr 就是带了引用计数的指针，所以上面的示例代码中，在 c++ 的真实实现就是：

1
2
3
4

{
    Foo *f = std::make_shared<Foo>();
    ... // using f, even passing to another function.
}

另外，为了解决循环引用的问题，又提供了 weak_ptr，被弱引用的 share_ptr 计数器不会 +1。

至于什么时候需要用 weak_ptr，这个锅又甩给使用者了，如果不小心写出了引用循环，那也是程序员的锅。

至于，unique_ptr 更像是针对一种常用的使用情况的定制，优化。

实现机制

比如这个示例：

1

auto f = std::make_shared<Foo>();

简单来说，分为这两层：

1

share_ptr => _Sp_counted_base

通过 make_shared 构造出来的智能指针，实际是一个 shared_ptr 对象，这个对象基本就是个空壳，指向内部的 _Sp_counted_base 对象。
而 _Sp_counted_base 对象则包含了：

1. use_count 计数器
2. weak_count 计数器
3. 实际 Foo 对象的指针

shared_ptr 对象拷贝的时候，会让 _Sp_counted_base->use_count + 1，析构的时候，会让 _Sp_counted_base->use_count - 1。
_Sp_counted_base 会在 use_count = 0 时，销毁 Foo 对象。

类似的，weak_ptr 则影响的是 weak_count，当 use_count = 0 && weak_count = 0 时，_Sp_counted_base 自身会被析构销毁。
这也就保证了 weak_ptr 不会访问野指针。

通过汇编代码，我们也可以看到 ~shared_ptr() 这个关键的析构调用，这是智能指针操作计数器的精髓。

1
2
3

40a0bf:       e8 68 02 00 00          call   40a32c <std::shared_ptr<Foo> std::make_shared<Foo>()>
...
40a0f2:       e8 9d 01 00 00          call   40a294 <std::shared_ptr<Foo>::~shared_ptr()>

总结

个人感觉，c++ 的智能指针设计，还是很精巧的。
利用了局部对象的自动析构，自定义拷贝函数，析构函数，等等隐藏了很多的细节，使用体验上也很大程度的接近于自动 GC，确实能很大程度的降低程序员在这方面的心智负担。

不过，也是有些坑需要避免的，比如循环引用。我们多了解一些内部实现机制，则可以更好的用好智能指针，尽量少踩坑。

前言

从 c 到可执行文件，包含了 编译 和 链接 这两步。通常在编译构建 c 项目的时候，也可以在 make 的过程中，看到 编译 和 链接 这种中间步骤。

然而，go 在这方面，有更进一步的封装，直接跑 go build 就行了，也不知道背后干了个啥。

最近因为搞 cgo 的优化，需要了解这里面的过程，记录一下的。

编译过程

底层还是分为 编译 和 链接 这两步，go build 可以类比为 go 标准的 make 工具。

对于 go 编译器而言，go 是提供给用户的统一的命令，实际上它还包含了很多其他的执行程序，比如 compile, asm, cgo, link 等。

go build 的执行过程，跟常见的 make 是类似的，大致有这么些事情：

1. 调用 compile 将 go 文件（以及依赖文件）编译为 .a 文件
2. 注意，这一步也是有缓存的，原文件没变更，则直接 copy .a 文件
3. 如果期间有 .s 文件，则用 asm 来编译
4. 如果有 import C，则调用 cgo 先生成一段 go 文件
5. 最后，通过 link 链接成最终的可执行文件

如果想看具体的编译过程，可以指定 -x，比如：

1
2

# -work 表示保留编译时的临时目录
go build -x -work .

值得一提的是，go test 也是先 build 生成一个，封装了测试框架的可执行文件，所以，build 的参数也同样可用。
比如：

1

go test -x -work

PS: go test 默认编译出来的是不带调试符号的，如果需要调试，可以加上 -o file 指定可执行文件，这样可以启用调试符号。
（貌似这个在 MacOS 上并不有效，还是 Linux 上可靠 :<）

自举过程

go 语言是完成自举了的，自举大致过程：

首先需要一个老版本的 go，1.4+，先用老的 go，编译 cmd/dist，生成 dist 可执行文件；再用这个 dist 来完成新版本 go 的编译。

在输出日志中，可以看到一下主要步骤：

1
2
3
4
5
6
7
8
9
10
11
12
13

# 老的 go 编译 cmd/dist 
Building Go cmd/dist using /path/to/old/go. (go1.14.15 linux/amd64)
# 接下来的几步，都是 cmd/dist 来执行的
# 老的 go，编译新代码的工具链，compile, asm, link, cgo
Building Go toolchain1 using /path/to/old/go.
# 新工具链，编译 go 命令，这里叫 go_bootstrap
Building Go bootstrap cmd/go (go_bootstrap) using Go toolchain1.
# 新的 go_bootstrap，重新编译工具链，以为 toolchain1 没有 buildid
Building Go toolchain2 using go_bootstrap and Go toolchain1.
# 再来一回，还是因为 buildid，为了更加一致
Building Go toolchain3 using go_bootstrap and Go toolchain2.
# 使用 go_bootstrap，编译完整的 go
Building packages and commands for linux/amd64.

简单解释一下：

1. dist 只是一个封装的临时，编译的时候，还是用的 compile, link 这种编译工具（也就是 toolchain）
2. 先用老的 go 重新编译新的 toolchain，然后再用新的 toolchain 编译新的 go（中间有一些重复编译 toolchain，不是那么重要）

如果想看具体的编译过程，可以指定 -v=5，比如：

1

bash -x all.bash -v=5

总结

go 对编译构建工具都提供了完整的封装，这个对于使用者而言，确实是更方便了，不需要自己折腾 Makefile，或者 bazel 这种构建工具了。

其具体过程，则跟常见的构建工具是类似的，分开编译，中间结果缓存，最后链接。

平常开发倒是用不着了解这些，不过要是修改 go 本身的话，对这些过程还是得比较清楚才行了；尤其是跑测试的时候，dist 命令中的 test，又是封装了一层编译的测试过程，这里面一环套一环的，还是比较多细节的。

go 提供了很多的内存指标，多了就容易分不清楚，本文解读几个容易让人迷糊的指标。

内存管理机制

磨刀不误砍柴工，我们先了解下 go 如何管理内存的。

首先，go 是 runtime 自己管理内存的，并没有依赖 libc 这种内存分配器。
具体而言，就是 runtime 自己直接用 mmap 从操作系统申请内存，供自己使用，没有中间商赚差价。

不过，也只是这种中间商角色，go runtime 自己来干了。
因为从操作系统申请内存，都是按页来申请，go 中的内存对象可以是任意大小的。
所以，go runtime 搞了个 mheap 数据结构，来维护所有申请到的内存，还搞了 mcentral, mcache, span 好多级来管理。

为了分配不同大小的内存对象，go 分了 67 个级别的 span，每个级别的 span 对应一个 size，可以理解为这个 size 的内存池。
分配内存的时候，从 size 最小且合适的 span 中分配一个出来。
是的，这种搞法是会浪费一些内存，不过可以比较好的解决，内存碎片的问题。

其他细节这里就先不展开了，简单而言，通常 C 程序用的 libc 中的内存分配器的活，go runtime 也自己干了。

与操作系统交互

当现有的 span 没有空闲的内存块时，go runtime 会通过 mmap 从操作系统申请内存。

但是，有意思的是，go runtime 释放内存的时候，并不是用 munmap，而是用的 madvise。
其中区别是，munmap 是将整个地址空间都还给系统，madvise 并不会将地址空间归还，而只是给系统一个建议（advise），说这个地址空间对应的物理内存，go runtime 暂时不用了，系统可以释放了，但是虚拟地址空间还是留着的。
下一次 go runtime 需要的时候，再通过 madvise 让系统为这个地址空间准备物理内存。

这里有个小插曲，go 1.12 版本，将 madvise 的参数，也就是给系统的建议，从默认 MADV_DONTNEED 改成了默认 MADV_FREE。
比起 MADV_DONTNEED，MADV_FREE 会更激进一些，操作系统并不会立马释放物理内存，而只是在物理内存比较紧张的时候，再真的释放。
这么改的目的是优化，可以减少下一次需要的时候，会触发的 pagefault 行为。

只是，这个副作用也比较明显的，没有释放的物理内存还是归属于 go 程序，所以 RSS 也算在 go 程序的头上，这个对于指标理解会造成很大的困扰，也更容易造成 OOM。

所以，后面又改回了默认 MADV_FREE，具体可见这个 CL：https://go-review.googlesource.com/c/go/+/267100/

内存指标

回到主题，go runtime 提供了很多的内存指标，文档也写得挺清楚的。
https://pkg.go.dev/runtime#MemStats

选几个常用的指标，做些个人直白解读：

HeapReleased

已经释放给系统，只保留了地址空间的内存大小

HeapIdle

处于空闲状态的 span 的内存大小

注意，这里包含了 HeapReleased。
HeapIdle - HeapReleased，就是 go runtime 目前预留的空闲内存池，
分配内存的时候，会优先从这里找合适的。

HeapInuse

处于被使用的 span 的内存大小

需要注意的是，如果 span 里有一个在使用的 GC object，整个 span 也处于 inuse 状态。
对象 Inused，包括：真实 alive（被 GC root 引用）；新申请还没有被 mark；mark 标记死亡，但是还没有 sweep 掉。

HeapSys

总共从系统申请的内存地址大小
注意并不是 RSS，有两种可能使得这个值与 RSS 不一样：

1. 申请了地址空间，但是没有读写，系统并不会分配真实物理内存
2. 物理内存释放给系统了，但是地址空间还是保留的，也就是 HeapReleased.

当然，还有不在 heap 管理的 RSS。

HeapAlloc

GC 管理的对象的大小

注意，是 object 粒度，不是 span。HeapInuse - HeapAlloc，也就是 Inused span 中还剩余的空间内存块。
这个语义跟 Inused 类似，除了包含活对象，还包括 mark 标记死亡，但是还没 sweep 调用的。
不过，如果 sweep 掉了，也就不算在内了，即使内存还没有还给系统。

StackInuse

被当做 stack 正在使用的 span 的大小

没有 StackIdle，因为 stack 和 heap，其实都是通过 mheap 那一套机制管理的，Idle 的 span，都算在 HeapIdle 里面了。

总结

go 舍弃了 libc 这类内存分配管理的中间商，自己重新撸一套，确实可以看有一些新花样出来（不只提到的这些，还有很多新花样绑定在 go 自己的内存分配管理实现上了），并不是简单的重复造轮子。

至于指标的含义，确实是指标太多了，每个都记住了估计是很难的。
个人的做法，理解清楚原理，搞清楚几个常用的，没记住的，用的时候再翻文档吧。

最近学习了 go 语言内置的 heap profile 实现机制，就像一个精致机械手表。

问题

首先，go 语言有自动的垃圾回收，已经很大程度的降低了程序员的心智负担。
需要的时候，直接申请使用即可，不需要手动的显示释放内存。
不过呢，也还是会经常碰到内存泄漏，内存占用高的问题。

作为内存分析工具，主要是需要解释两个问题：

1. 内存从哪里申请来的
2. 又是为什么没有被释放

go 内置的 pprof heap profile 则可以很好的回答第一个问题。

ps: 问题二，通常可以根据问题一的答案，再结合看代码是可以搞清楚的，不过有些复杂的场景下，也还是需要借助工具来分析定位，这个我们以后有空再说。

解决办法

通常情况下，我们并不会关心那些已经被 GC 回收掉的临时内存，而只关心还没有被回收的内存。
所以，我们需要追踪内存分配和释放这两个动作。

采样

因为内存申请是程序运行过程中一个比较高频的行为，为了减少开销，一个有效的方法是采样，仅仅追踪部分行为。
go 默认是每分配 512KB 内存采样一次，可以通过环境变量 memprofilerate 来修改。

实现方式就是，在每次 malloc 的时候，维护一个计数器，累计申请的内存达到阈值即进行采样，并开始下一个计数周期。

采样的时候，需要记录以下几个信息：

1. 当前调用栈。注意并不是最终可见的文本调用栈，仅需要记录每层栈帧的 PC 值。
2. 申请的大小。这里会是一个统计周期内的累计值。

每个调用栈，会创建一个 memory Record，也就是源码中的 mp 对象，进行归类。

并且会为本次采样的内存块，记录一个 special（且 special 会关联到 mp），会在 GC sweep 处理 finalizer 的阶段，处理这个内存块的释放逻辑。
此时的处理逻辑也就非常简单了，直接在关联的 mp 中统计已经释放的内存大小即可，O(1) 操作，非常干净。

周期

因为内存分配是会持续发生的事件，而内存回收又是另外一个独立的 GC 周期，这个时候精准卡点就显得非常重要了。

go 中的每个 mp，并不是全局的实时统计，而是会分为好几个区域，按照 GC 周期的进行，依序往前推进（是的，就像机械手表那样精巧）

1. active，这是最终汇总统计的，通过 pprof heap profile 读取的数据，通常就是 active 里的汇总数据
2. feature[3]，这里是统计正在发生的，长度为 3 的一个数组。

推进器则是 cycle 计数器，在 GC mark 完成，start the world 之前，cycle 会 +1。

结合长度为 3 的 feature 数组：

1. feature[(c+2)%3]: malloc 时记录到这个位置，表示正在申请的。
2. feature[(c+1)%3]: sweep 时从位置去统计 free，表示正在 sweep 或者将要被 sweep。
3. feature[c%3]: sweep 开始之前，将这个 c 中的值，累加到 active 中，表示已经经过一个 GC 周期 sweep 的。

这样的方式，非常的精准，和 GC 周期完美的结合起来了。
active 中统计是：从程序启动开始，到某一次 GC 周期完成之后，还没有释放的内存。
至于具体是哪个 GC 周期，就是说不好了，可能最多会落后两个 GC 周期。

用途

了解这些是有啥用呢，当然是为了更好的分析内存问题。

有些时候，内存并不会持续增长，而只是突增一下又恢复了，我们需要一个非常精准的方式，拿到这一次突增的的原因。
这时我们需要这样一种分析思路，基于 GC 周期的内存 profile，当然，这也是 pprof heap profile 思路的延续。

突增的危害

通常情况下，内存突增一下又恢复，并不是什么大问题，只是短时间的让 GC 变得更活跃。
但是，这种异常的波动，也不可简单忽略

1. 内存突增，意味着内存申请/回收变得频繁，可能是有非预期的大批内存申请，造成瞬间的响应时间变长。
2. 推高 GC goal，也就是下一次 GC 的阈值会变高，如果内存相对紧张，会导致 OOM。

解决办法

代码已经提交到 MOSN 社区的 holmes：
https://github.com/mosn/holmes/pull/54

具体的做法是：

1. 在每次 GC Mark 结束之后，检查本次 GC 之后的依然 live 内存量，是否有突增。这个值基本就决定了下一次的 GC goal。
2. 如果有突增，就获取当前 active 的 heap profile。注意：此时 profile 中的数据，并不包含突增的内存。
3. 并且，在下一次 GC 完成之后，再一次获取 active 的 heap profile。此时 profile 中的数据，就多了刚才突增的内存。

我们需要获取两次 heap profile，使用 pprof 的 base 功能，就可以精准地获取突增的那一个 GC 周期，到底新增了什么内存。

ps: 当然 GC goal 被推高的问题，也还有另外的办法来缓解/解决，也就是动态的 SetGCPercent，这里也暂且不表。

案例

上面的 PR 中也有一个测试案例：
https://github.com/mosn/holmes/blob/15e2b9bedf130993d3a4e835290b2065278e062f/example/gcheap/README.md

描述的是这样一个场景：

1. 长期存活内存基本保持在 10MB
2. /rand，表示正常的接口，申请的内存很快能被回收，这个接口一直被频繁的调用
3. /spike，表示异常的接口，突然会申请 10MB 内存，并且保持一段时间之后才释放，这个接口偶尔有调用

具体的过程就不再重复描述了，最终我们可以看到通过 holmes 的 gcHeap 检查，可以精准地抓到 /spike 这个偶尔调用的异常接口的现场。

最后

go 语言的 pprof heap profile 是很强大的基础能力，对于那种持续泄漏的场景，我们只需要取两个点的 profile 就可以分析出来。
但是，对于非持续的内存增长毛刺，则需要我们充分理解它的工作机制，才能精准地抓到问题现场。

另外，还有一个中内存 “突增”，突然申请了大量临时内存，并且能立马被 GC 回收掉，并不会导致 GC goal 被推高。
这种情况，其实危险要相对小一点，坏处就是 GC 频率变高了。

或者，压根就不是 “突增”，就是 GC 频率一直很快，一直有大量的临时内存申请。

这种情况，其实也可以借助 heap profile 来精准区分，按照上面的分析，我们只需要获取 feature[c+2] 中的数据即可。
那个就是新增内存的来源，我们可以根据这个来分析哪些临时内存是可以复用的，也是一个很有效的优化方法。

只不过，目前的 go runtime 中并没有一个很好的 callback 来实现精准的读取 feature[c+2]。
而且看起来也不是很有必要的样子，后面有需要的话，可以给 go 提个 proposal，听听 rsc 大佬的意见。

用了差不多十年的 vim，近期转到 vscode 了，记录一些使用心得

缘起

原来一直用 vim，感觉还挺顺手的。

大约去年底的时候，要看 hotspot JVM 的 c++ 代码，瞬间觉得 vim 不够用了。因为 c++ 太复杂了，重载/虚函数 之类的，函数跳转就很难搞了。vim 通常是搭配 ctags 来做函数跳转，看 JVM 代码的时候，一个函数跳转，能出来好几页的候选项，瞬间就头大了。
当时看隔壁晖哥用 vscode 还挺方便的，就也装了用起来了，确实感觉耳目一新。

最近主要看 go 代码，也就顺势切到 vscode 了。

初印象

vscode 总体感觉是比较成熟，各种插件比较丰富，如果碰到错误，也能搜到解决办法；这也是随大流的好处，坑基本都有人踩过了。

vscode 的好用，主要是依赖插件，选择合适的插件就很关键了。因为 vscode 提供的应用市场，插件是有第三方提供的，质量也可能参差不齐，装插件的时候，需要一些时间精力来挑选。

引申一下，这种应用市场的机制，一方面可以让插件丰富一起来，充分发挥开放平台的优势；另一方面，对于插件的质量，其实是比较容易失控的，也是需要平台方有机制来保障的。
比如下载数量，好评数，都是比较好的机制。

接下来，记录一些我这边用着比较好的插件。

Vim

虽然用上了 vscode，但是我还是喜欢 vim 的操作习惯。
这个 Vim 插件可以保留 vim 下的大部分操作习惯，所以感觉切换过来还比较的顺畅。

Remote - SSH

虽然用得是 Mac 电脑，不过一直习惯 Linux 上的开发环境，所以一直都是用虚拟机来开发。
以前是直接 ssh 到 Ubuntu 上来开发，现在这个 Remote - SSH 插件就显得很必要的了。

另外，Ctrl + ~ 可以唤出一个 terminal 执行 shell，也是挺方便的，有些时候还是需要执行一些 shell 的。

至此，原本的主要的 ssh + vim 流程，就有了完整的替代了。

GitLens

这个插件对我而言，主要是：

1. 可以方便的显示每行代码的最后修改记录，包括作者，commit 等。
2. 可以本地看某个文件的 diff，左右对比的那种，确实对眼睛比较友好。

原来 vim 里也有插件能做类似的事情，不过体验比 GitLens 要差一些，这算切换过来的甜头了。

c/c++

这个是当时看 jvm 源码时用的插件。

跟 Vim 比起来，最大的感触是，函数跳转就顺畅多了。很庆幸当时旁边坐了晖哥，哈哈，谢谢晖哥带我走上 vscode 的坑。

go

go 官方出的这个插件确实很棒，比如：

1. 代码格式自动调整
2. 自动补全提醒
3. 非法代码提醒，比如未定义变量
4. 自动引入/删除 import
5. 跳转：函数定义/引用

原来没有折腾过 vim 下的 go 插件，应该也有能类似做到这些的插件，不过可能没有官方出的这个插件好

不过也踩到一个坑，vendor 下定义了一个函数，同时 vendor 下的其他 package 有引用这个函数，但是找函数引用的时候，会说没有引用。
这个坑暂时还没有找到解法…

现在有点犹豫要不要入 goland 的坑…

debug

以前搞 c 开发的调试，通常是徒手 gdb 搞起，这次切换后也尝试了下编辑器的调试功能。

在编辑器打断点确实挺爽的，之前虽然见过，不过一直也没有真实体会过，体会了一下，确实是挺好的。
不过也有一个不好的点，断点之后，有时候想看下汇编代码，看看寄存器的值，或者想汇编的单步跟踪一下，现在是不知道怎么弄了。
或许有解决办法，只是我还不知道…

另外是，编辑器 debug 的学习成本也有一丢丢，主要是需要配置下 launch.json，还可能需要 tasks.json。

最近分析 viewcode 一个小 bug 的时候，碰到了调试的时候，不再接受标准输入的问题，按照这个路子才搞定，也是费了一些功夫。
https://blog.csdn.net/weixin_42529589/article/details/104583672

总结

vscode 目前给我的体验还是不错滴，不过也有点纠结要不要切到 goland …
主要是周围的人都用 goland，我这踩到的 vscode 的坑，都没个人来请教，有点忧伤 …

之前 看书 的时候，对于 go 的 interface 机制，对我个人而言，感觉挺新颖的，又不得其要领，心中留下了不少疑惑。
实践了一些小例子，对有了基本的了解，记录下这篇文章。

struct method

在了解 interface 之前，我们先看看 struct method 的用法，这个就比较有面向对象的感觉，fields + methods。
第 6 行中的 (r Rectangle) 的用法有点像 Lua 语法糖里的 self，Java 里面的 this。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

type Rectangle struct {
    a, b uint64
}

//go:noinline
func (r Rectangle) perimeter() uint64 {
    return (r.a * r.b) * 2
}

func main() {
    s := Rectangle{4, 5}
    p := s.perimeter()

    fmt.Printf("perimeter: %v\n", p)
}

之前看书的时候，struct method 和 interface 是一起出现的，所以心中比较疑惑这两者的关系，这回算是清楚了。

另外，这里有一个有趣的优化，我们看下生成的汇编代码，这里直接把 struct 里的 field 当做参数传给 perimeter 函数了。

1
2
3
4

MOVL $0x4, AX
MOVL $0x5, BX
NOPW
CALL main.Rectangle.perimeter(SB)

PS：去掉第 5 行 go:noinline 的话，连函数调用都会被优化掉了。

Interface 抽象的是什么

struct + method 已经有面向对象的感觉了，那么 interface 抽象的又是什么呢？

先看一个示例，这里申明了一个叫 Shape 的 interface，其有一个 perimeter 的方法。

1
2
3

type Shape interface {
    perimeter() uint64
}

如果只有 Rectangle 和 Shape 的话，看起来 Shape 看起来没啥用。
如果再加一个 Triangle，就比较好懂了，此时 Rectangle 和 Triangle 都实现了 Shape 接口。

1
2
3
4
5
6
7

type Triangle struct {
    a, b, c uint64
}

func (t Triangle) perimeter() uint64 {
    return t.a + t.b + t.c
}

接下来就可以这样使用了，Rectangle 和 Triangle 都实现了 Shape 接口。

1
2
3
4
5
6
7
8
9
10

var s Shape
s = Rectangle{4, 5}
p := s.perimeter()

fmt.Printf("Rectangle perimeter: %v\n", p)

s = Triangle{3, 4, 5}
p = s.perimeter()

fmt.Printf("Triangle perimeter: %v\n", p)

从我的理解而言，interface 是一种更高层次的抽象，表示具有某些能力（method）的对象，并不是特指某个对象（struct）；只要某个 struct 具有 interface 定义的所有 method，则这个 struct 即自动实现了这个 interface。

有了 interface 抽象之后，我们可以只关心能力（method）而不用关心其具体的实现（struct）。

对比 C 语言常规的接口

乍一眼看 interface 的定义的时候，很像 C 语言暴露在 .h 头文件里的接口函数；但是实际上二者差距很大。

C 语言中的接口函数，更像 go package 中 export 的 function，只是公共函数而已。
interface 则是面向对象的概念，不仅仅是定义的 method 有一个隐藏的 struct 参数，而且一个 interface 变量真的会绑定一个真实的 struct。

interface 也是 go 语言里的一等公民，跟 struct 同等地位，这个跟 C 里面的函数接口就完全不是一回事了。

对比 go 语言自己的 struct

虽然 interface 和 struct 在调用 method 的使用，用法很像；但是这两也不是一回事。

interface 是更高一层的抽象，由不同的 struct 都可以实现某个接口；
而且 interface 变量只能调用 interface 申明的 method，不能调用绑定的 struct 的其他 method。

interface 的实现

里面的解释其实还是有些粗糙，看下 interface 的实现机制，就比较容易理解了。

首先，interface 是一等公民，上面例子里的 var s Shape，实际上是构建了如下这样一个 struct。
tab 表示 interface 的一些基本信息，data 则指向了一个具体的 struct。

1
2
3
4

type iface struct {
	tab  *itab
	data unsafe.Pointer
}

我们看下上面例子中，interface 调用过程的实际汇编代码：

1
2
3
4
5
6
7
8

MOVQ $0x4, 0x38(SP)
MOVQ $0x5, 0x40(SP)
LEAQ go.itab.main.Rectangle,main.Shape(SB), AX
LEAQ 0x38(SP), BX
CALL runtime.convT2Inoptr(SB)
MOVQ 0x18(AX), CX
MOVQ BX, AX
CALL CX

1. 1-2 行，在栈上构建了一个 Rectangle struct
2. 3-5 行，把 itab 和 struct 地址，传给 convT2Inoptr，由其构建一个堆上的 interface 变量，即 iface struct
3. 6 行：获取 iface 中 method perimeter 的地址，main.(*Rectangle).perimeter 这个函数
4. 7-8 行，相当于这个效果，perimeter(&struct Rectangle)

其中 convT2Inoptr 的核心代码如下，即是在堆上构建 iface 的过程。

1
2
3
4
5
6
7
8

func convT2Inoptr(tab *itab, elem unsafe.Pointer) (i iface) {
	t := tab._type
	x := mallocgc(t.size, t, false)
	memmove(x, elem, t.size)
	i.tab = tab
	i.data = x
	return
}

这里有一个比较有意思的地方，第 7 行 MOVQ BX, AX 中的 BX 并不是来自第 4 行的赋值，因为 go function call ABI 中，所有寄存器都是 caller-saved 的。
我们看下 convT2Inoptr 的汇编代码，可以看到它是这样处理返回值的，直接把 iface 中的两个成员返回了；按照源码的字面意思，应该只有一个返回值的。

1
2
3
4
5

MOVQ 0x40(SP), AX
MOVQ 0x18(SP), BX
MOVQ 0x30(SP), BP
ADDQ $0x38, SP
RET

总结

go interface 是一个挺有意思的设计，作为一等公民，跟普通类型无异，可以构建普通的 interface 变量。

另外在实现的时候，对于 iface 这种很小的 struct，go 编译器做了比较有意思的优化，直接把 struct 中的成员展开，用多个值来表示这个 struct。这样可以更充分的利用寄存器，更好的发挥 go function call ABI 的特性。

上一篇文章 Goroutine 调度 - 网络调用 介绍了网络调用过程中，Goroutine 的切换过程。
对于网络操作而言，Linux 操作系统本身就提供了 epoll 机制，所以对于应用层比较友好。

那么对于其他系统调用，比如普通的文件读写，那是如何做到非阻塞的呢？
本文在介绍 cgo 的实现机制的时候，也会介绍到这里的调度机制。
因为对于 go 而言，C 函数默认是阻塞不安全的，被很保守的对待处理了，毕竟 go 并不是设计为嵌入式语言，go 自己才应该是主角。

跨语言函数调用

首先，对于 CPU 而言，函数调用也就是个 call 指令，对应的是将当前 PC 值压栈，同时 JMP 到新函数的指令位置。

那么 go 和 c 的跨语言函数调用，存在哪些难点呢？

1. 数据类型不一样，go 和 c 都有自己的一套类型系统，参数/返回值可能需要做类型转换
2. 函数调用的 ABI 不一样
   go 1.7 之后的函数调用 ABI 中，所有寄存器都是 caller saved。
   C 语言的 ABI 中 caller-saved 和 callee saved 基本一半一半
3. Goroutine 的栈空间可能不够用
   Goroutine 的栈空间初始值只有 2 kB，是在执行 go 函数的时候，按需增长的。
   但是执行到 c 函数之后，c 函数里是不会检查栈空间是否够用的了。
4. C 调用 go 的时候，如何绑定 M 和 P

go 调用 c

cgo 有两种用法：

1. go 调用 c
2. c 调用 go

我们先看 go 调用 c 这种简单的情况，如下面的例子。
为了方便，我们使用的内联 C 代码的方式，直接在 go 源码里定义了一个 c 函数。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

/*
long add(long a, long b) {
    return a + b;
}
*/
import "C"
import "fmt"

func main() {
    var a C.long = 2
    var b C.long = 3

    r1 := C.add(a, b)

    fmt.Printf("%d + %d = %d\n", a, b, r1)
}

执行过程

这个示例的最终执行路径是这样子的：

1
2
3
4
5

1. main.main
2. main._Cfunc_add (把函数参数写入到内存，一个 struct 中)
3. runtime.cgocall (entersyscall + 切换到 g0 系统栈)
4. _cgo_05b35a9f2a70_Cfunc_add (从内存读取函数参数)
5. add (c 生成的函数)

调用开销

我们可以到其中额外的开销：

1. 2 和 4 主要是对接 go 和 C 函数调用 ABI，将参数通过内存中转了一下
2. 因为 C 函数中可能会调用一些阻塞操作，所以需要 entersyscall 做好调度准备
3. 同时因为 C 函数需要的栈空间未知，切到 g0 栈是更安全的做法

所以，go 调用 c 很频繁的话，这部分开销还是值得关注的。

如下是 add 的 go 函数实现，我对比了一下，go->go 调用是纳秒级别的开销，go->C 则是接近 100 纳秒级别的开销了。
当然，这个 add 函数只需要非常简单的一条 add 指令，真实情况下肯定不会这么简单，所以真实情况下的差距则肯定不会这么大了。

1
2
3
4

//go:noinline
func add(a int64, b int64) int64 {
    return a + b
}

实现细节

使用 go tool cgo test.go 可以看到 cgo 生成源文件，在 _obj 目录下。

1. _Cfunc_add 是 cgo 自动生成的 go 函数。

这里有一个细节，看起来只有 p0 的地址当做参数传递给了 _cgo_runtime_cgocall 也就是 runtime.cgo，p1 并没有被用到。
实际上，p0 和 p1 并不是通过寄存器传参的，而是通过栈内存传递的，p1 总是跟随在 p0 后面。

1
2
3
4
5
6
7
8
9

//go:cgo_unsafe_args
func _Cfunc_add(p0 _Ctype_long, p1 _Ctype_long) (r1 _Ctype_long) {
        _cgo_runtime_cgocall(_cgo_9c59eeeff222_Cfunc_add, uintptr(unsafe.Pointer(&p0)))
        if _Cgo_always_false {
                _Cgo_use(p0)
                _Cgo_use(p1)
        }
        return
}

2. _cgo_05b35a9f2a70_Cfunc_add 是 cgo 自动生成的 C 函数

这里的参数 v 这是上面的 p0 地址。这里定义了一个 struct 来描述 p0 和 p1 的内存布局。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

void
_cgo_9c59eeeff222_Cfunc_add(void *v)
{
        struct {
                long int p0;
                long int p1;
                long int r;
        } __attribute__((__packed__, __gcc_struct__)) *_cgo_a = v;
        char *_cgo_stktop = _cgo_topofstack();
        __typeof__(_cgo_a->r) _cgo_r;
        _cgo_tsan_acquire();
        _cgo_r = add(_cgo_a->p0, _cgo_a->p1);
        _cgo_tsan_release();
        _cgo_a = (void*)((char*)_cgo_a + (_cgo_topofstack() - _cgo_stktop));
        _cgo_a->r = _cgo_r;
        _cgo_msan_write(&_cgo_a->r, sizeof(_cgo_a->r));
}

3. p0 和 p2 具体是由 _Cfunc_add 的调用方来写入

也就是 main.main 这个入口函数了，通过 go tool objdump -s main.main test 我们可以看到如下的汇编，两个参数确实是被放入了栈内存中。

1
2
3

MOVQ $0x2, 0(SP)
MOVQ $0x3, 0x8(SP)
CALL main._Cfunc_add.abi0(SB)

1

PS：示例中的 c 函数参数没有用 int 类型，因为用 int 的话，会有碰到一个优化，两个 int 合并到一个 long 了，汇编指令看起来就没那么直观了

Goroutine 调度

其中调度相关的逻辑主要在 runtime.cgocall 中的 entersyscall，

1. 将当前 P 和 M 解除绑定，将 P 记录到 M.oldp
2. 将当前 P 的状态改为 _Psyscall

需要注意的是：

1. 此时并没有将 P 释放给其他 M 使用
   而是在另外的 sysmon 线程中不定期检查所有 P 的状态，具体逻辑在 retake 函数中：
   简单的点说，如果 P 处于 _Psyscall 超过一个 sysmon 的轮询周期（至少 20us）则会将 P 切换到 _Pidle 状态，供其他 M 使用。

2. M 线程还是由操作系统调度运行的
   即使在 P 被抢走的情况下，M 也还是继续运行的，毕竟操作系统只认识 M。
   当 M 中的任务（syscall or C function call）完成后继续运行的，会执行到 exitsyscall。
   此时会按照这个顺序去执行：绑定 oldp 恢复执行，绑定其他空闲的 P 恢复执行，放回到运行队列等待调度。

总结一下，简单来说：

1. entersyscall 标记进入可抢占状态
2. sysmon 轮询检查，将长期运行的 P 释放
3. exitsyscall 恢复 G 的运行

1

PS：runtime.cgocall 中另外一个关键逻辑是：asmcgocall(fn, arg)，这个是切换到 g0 栈执行 fn 这个 C 函数

C 调用 go

C 调用 go 又分为两种情况：

1. 原生 C 调用 go
2. go -> C -> go

这里我们看下第一种情况：

go 生成 so

第一步，我们需要从 go 代码生成 so，并且生成 .h 的头文件，供 C 代码使用。

如下的 go 源码：

1
2
3
4
5
6
7
8

import "C"

//export AddFromGo
func AddFromGo(a int64, b int64) int64 {
    return a + b
}

func main() {}

通过如下命令，会生成 libgo-hello.so 和 libgo-hello.h 头文件：

1

go build -o libgo-hello.so -buildmode=c-shared hello.go

使用 go 生成的 so

有了头文件和 so，我们就可以当做普通库来使用了，比如下面的例子：

1
2
3
4
5
6
7
8
9
10
11

#include <stdio.h>
#include "libgo-hello.h"

int main() {
    long a = 2;
    long b = 3;

    long r1 = AddFromGo(a, b);

    printf("%ld + %ld = %ld\n", a, b, r1);
}

如下方式编译为可执行文件：

1

gcc -g -o hello hello.c -l go-hello -L. -Wl,-rpath,.

执行流程

这个示例的最终执行路径是这样子的：

1
2
3
4
5
6

1. main
2. AddFromGo (libgo-hello.so 导出的函数，将函数参数写入到内存，一个 struct 中)
3. crosscall2 (准备进入 cgocallback 这个 go 函数，对接两边的 call ABI)
4. runtime.cgocallback （获取 M 和 P 等等，逻辑比较多）
5. _cgoexp_51fb23d6311d_AddFromGo (从内存读取参数)
6. main.AddFromGo

函数参数这部分，和 go->C 没什么区别，都是将参数放入到一个 struct，然后固定传这个 struct 的地址。

如何获取 M 和 P

1. libgo-hello.so 加载的时候，会触发 go runtime 的初始化，创建 M 和 P；是的，除了 c 主程序的线程，还会另外创建一些 go 的 runtime 线程。
2. AddFromGo 函数中会检查 go runtime 是否已经初始化好了
3. 执行 main.AddFromGo 的时候，并没有真的切换到新的线程。而是当前线程获取一个伪装的 M，extra M，具体过程这块还没细看。

总结

相对而言，目前的实现里，go 和 C 之间的调用开销也还是比较高的。应该比普通的 Lua C API 调用还是高，虽然传参都会经过内存，但是 go 还多了协程调度的逻辑。

优化的空间应该还是有的，对于某些 go 和 C 交互比较频繁，性能要求比较高的场景，应该还是可以搞一搞：

1. 引入 unsafe C function call
   这种 unsafe 的情况下，不再调用 entersyscall 和 exitsyscall，C function 阻塞的风险就甩给程序员了
   不过还是需要注意下，Gorountine 的抢占调度在这个情况是否会踩坑
2. 通过寄存器来传递参数，减少内存读写
   这个应该也可以搞，如果 1 实现了的话，应该相对容易一些，如果 1 没有的话，可能还比较难，或者效果也不明显了，毕竟中间又隔了好多的函数调用了。
3. 避免切到 g0 栈运行
   这个看起来不太好搞。
   如果在 unsafe 模式下，让程序员来指定 C 需要的 stack size 倒是可以搞；不过不可靠，很容易就指定错了，可能会出现诡异的问题，不可取。

上一篇文章 goroutine 调度概览 大概介绍了 Goroutine 调度的基本情况，这篇来看个具体的例子：网络调用。

协作式主动让出执行权

Goroutine 很多时候都是通过主动让出执行权的，主动让出的执行效率可以更高；就像自己主动搬砖和被人催着搬砖一样。
除了 runtime.Gosched 这种 go 代码里显式指定让出的（实际上应该会比较少用到），更多时候是由某些行为底层触发，网络调用则是一个典型的例子。

网络调用

对于网络的非阻塞实现，linux 下最常见的就是用 epoll，我们通过例子来看看 go 语言如何在语言级别把 epoll 的细节屏蔽。

以下是个简单例子，向 example.com:80 发起了一个 HTTP GET 请求，然后读取第一行响应。

1
2
3
4
5
6
7
8
9
10
11
12

conn, err := net.Dial("tcp", "example.com:80")
if err != nil {
    // handle err
}
fmt.Fprintf(conn, "GET / HTTP/1.0\r\n\r\n")

line, err := bufio.NewReader(conn).ReadString('\n')
if err != nil {
    // handle err
}

fmt.Println("line: ", line)

挂起

我们重点介绍发送之后，第一次读取数据的行为

1. 因为刚发送完，此时立马读取，肯定读不到数据，syscall.Read 会返回 EAGAIN
2. 接下来会调用 gopark 将当前 Goroutine 挂起

通过 gdb 可以看到这样的一个调用栈：

1
2
3
4
5
6
7
8
9

#0  runtime.gopark (unlockf={void (runtime.g *, void *, bool *)} 0x0, lock=0x7fffd00a0700, reason=2 '\002', traceEv=27 '\033', traceskip=5) at /home/dou/work/go/src/runtime/proc.go:349
#1  0x000000000042e5fe in runtime.netpollblock (pd=<optimized out>, mode=<optimized out>, waitio=<optimized out>) at /home/dou/work/go/src/runtime/netpoll.go:445
#2  0x000000000045c489 in internal/poll.runtime_pollWait (pd=<optimized out>, mode=140736683706112) at /home/dou/work/go/src/runtime/netpoll.go:229
#3  0x000000000048b0b2 in internal/poll.(*pollDesc).wait (pd=<optimized out>, mode=140736683706112, isFile=2) at /home/dou/work/go/src/internal/poll/fd_poll_runtime.go:84
#4  0x000000000048ba1a in internal/poll.(*pollDesc).waitRead (isFile=2, pd=<optimized out>) at /home/dou/work/go/src/internal/poll/fd_poll_runtime.go:89
#5  internal/poll.(*FD).Read (fd=0xc0001a8000, p=..., ~r1=<optimized out>, ~r2=...) at /home/dou/work/go/src/internal/poll/fd_unix.go:167
#6  0x00000000004ac629 in net.(*netFD).Read (fd=0xc0001a8000, p=...) at /home/dou/work/go/src/net/fd_posix.go:56
#7  0x00000000004b6965 in net.(*conn).Read (c=0xc000094008, b=...) at /home/dou/work/go/src/net/net.go:183
#8  0x00000000004c1d2e in net.(*TCPConn).Read (b=...) at <autogenerated>:1

补充一点：gopark 的核心逻辑是，切换到 g0 栈，执行 park_m。在 park_m （g0 栈）中再把当前 G 挂起。

恢复执行

上一步的 park_m 函数，除了会挂起当前 G，另外一个重要的任务就是执行 schedule 函数，挑一个新的 G 开始运行。

在上一篇介绍过，挑选一个新的 G 的过程中，就有 检查 netpoll 这一步。
我们可以在 gdb 中看到如下的调用栈：

1
2
3
4
5

#0  runtime.netpollready (toRun=0x7fffcaffc6c8, pd=0x7fffd00606d8, mode=119) at /home/dou/work/go/src/runtime/netpoll.go:372
#1  0x000000000042f057 in runtime.netpoll (delay=<optimized out>) at /home/dou/work/go/src/runtime/netpoll_epoll.go:176
#2  0x000000000043abd3 in runtime.findrunnable () at /home/dou/work/go/src/runtime/proc.go:2947
#3  0x000000000043bdd9 in runtime.schedule () at /home/dou/work/go/src/runtime/proc.go:3367
#4  0x000000000043c32d in runtime.park_m (gp=0xc000202000) at /home/dou/work/go/src/runtime/proc.go:3516

netpoll 中的核心逻辑即是调用 epoll_wait，获取一批已经准备就绪的 events，恢复这批 G 到 runable 状态，并运行第一个 G。

总结

对于非阻塞网络的实现，核心点是 EAGAIN 和 epoll_wait。
go 语言把这个细节隐藏到了语言/标准库内部，确实很大程度的降低了程序员的心智负担。

如上文 go 语言学习 中提到，GMP 是 go 语言的一个核心设计。对于 Goroutine 的调度机制，一直非常好奇，最近翻阅了源码，也做了一些小实验，算是有了个基本的理解，解释了心中的很多疑惑。

GMP 解释

G：Goroutine，用户态协程，表示一个执行任务，实际上是一个 Goroutine 数据结构 + 一段连续的内存当做 stack
M：Machine，实际是一个系统线程，操作系统调度的最小单元
P：Processor，虚拟处理器，实际上只是 runtime 中的数据结构，用于限制当前正在运行的 Goroutine 数量

几个知识点：

1. P 通常跟 CPU 核心数一样多，表示当前这个 go 程序可以占用几个 CPU 核心。
2. P 是需要绑定一个实际的 M 才能运行，毕竟系统线程才能真正的在物理 CPU 上执行任务。
3. 但是，M 通常会比 P 更多一些，比如碰到阻塞的操作，P 就会和 M 分离，如果有很多阻塞任务，M 就可能会非常多。

为什么需要调度

Goroutine 虽然底层 主要 是协作式的调度，但是调度的细节对于使用者则完全屏蔽了。
从这个角度看，Goroutine 很像操作系统的线程，即使底层有调度切换，但是让使用者认为 Goroutine/系统线程 是一直在运行的。

对于使用者而言，可以不关心，Goroutine 是何时被挂起的，又是何时恢复执行的（当然，为了写出更好的代码，我们肯定还是需要了解这些实现机制的）。

对于上层屏蔽了，就需要语言层面来处理了，也就有 runtime 里的调度机制了。

1

go 语言暴露的 runtime.Gosched 只是让当前 Goroutine 临时让出执行权，避免大计算任务的长期阻塞，并不是严格的挂起。跟 OpenResty 中 ngx.sleep(0) 的作用一样。

对比 Lua

相对于 Lua 这门嵌入式语言而言，则是完全把控制权交给了宿主程序。
具体来说，Lua 对外提供了挂起 yield 和 恢复 resume 的 API，由上层使用者来控制 coroutine 的执行。
当然，虽然需要使用者操心的事情更多，不过在嵌入式场景中，对于宿主程序某些方面反而更友好，可以更精确的控制程序的执行。
比如，并发协程的调度优先级，对于协程中执行的不同类型任务，我们希望可以有不同的优先级。
但是，Goroutine 是完全被平等对待的，上层没有办法控制调度的优先级；Lua 里则不存在这个问题，直接通过 lua_resume 恢复执行某个协程即可。

对比 OpenResty uthread

Goroutine 的使用体验 和 OpenResty 中的 uthread 使用非常类似，同步非阻塞，即：以同步的方式写代码，实际上是则是以异步非阻塞的方式执行。

Goroutine 是由 runtime 来驱动运行，OpenResty uthread 则是由 Nginx 的事件循环来驱动运行。
当然，实际上这两还是有些区别的，Goroutine 抽象在语言层面，对于很多的非网络系统调用，都实现了非阻塞的调度（虽然比较重，底层还是通过堆线程来实现）；OpenResty uthread 则只是对网络调用封装了同步非阻塞，对于其他的阻塞式系统调用，还是会阻塞当前 worker 进程的。

调度器的任务

对于协程调度而言，核心就两个任务：

1. 挂起
2. 恢复

挂起的核心在于选择时间点，Goroutine 有这么几种方式会挂起：

1. 协作式的主动让出
2. 进入系统调用发生了阻塞，被监控线程强制切走
3. Goroutine 执行时间太长，被中断信号切走

恢复逻辑则比较的固定，按照这个顺序查找可以执行的 Gorounine (runable)。

1. P.runnext 指向的 G
2. 本地队列
3. 全局队列
4. 检查 netpoll（timeout = 0)
5. 从其他 P 去偷 G
6. 检查 netpoll (timeout > 0)

对照如下经典的 GMP 模型图，会更好理解一些。

Goroutine 切换发生了什么

首先 Go 编译生成的机器指令，操作 Goroutine 栈的方式，跟 C 语言很像。
比如在 X64 CPU 架构下，通过 rsp 寄存器来指向栈顶，然后通过 rsp 的相对位置来操作栈内存。
所以，在 Goroutine 切换的时候，肯定会发生栈切换。

对比之下，Lua coroutine 的栈，则只是纯粹的一段内存，Lua coroutine 切换，并不需要改变 rsp 的值。

另外，每个 M 都有一个固定的 g0 栈，Goroutine 的切换实际上存在两次切栈操作，比如 g1 切换到 g2 的时候，会发生：

1. g1 让出执行权，切换到 g0 栈
2. g0 执行 scheduler，找到 g2 开始执行

因为 scheduler 的逻辑还是比较复杂的，不适合在 g1 上执行了。
要在 g1 上执行的话，至少需要在 g1 上预留比较多的空闲栈内存空间，否则就可能会栈溢出了。
当然 g0 还有其他用处，这个以后再说。

实际案例

准备了两个小例子，实际看看 Goroutine 是如何切换的。

1. 网络调用
2. 调用 C 函数

且听下回分解。