@
henglinli #7 我补充一点吧
go runtime，严格来讲就是以 golang 下 以 goroutine 结合管道通信的并发模型，这个并发模型是基于 stackfull 的协程模型，相反的是 stackless 的协程模型，而传统其它语言可能是基于线程池以及锁的并发模型 ，有兴趣可以看 stackfull 跟 stackless 的区别，前者会占用空间，后者对内存空间友好，但是现在是 2021 年了，谁家老板买不起 2T 内存？ golang 选的是 stackfull 协程模型，当然这里比较简单，下面会详细介绍，有兴趣深入还是根据我的关键字去找书看。
然后 stackfull 的本质就是 每个协程有自己的栈幁，具体我没有关注过 goroutine 的栈幁结构，但是从我观察 goroutine 进入内核态的汇编代码，做了一次 go 的调用约定 到 amd64 fastcall 的调用约定转换，基本上可以确认 golang 内部的函数调用约定以及栈幁结构 应该是平台无关化的，另外 golang 貌似是不支持二进制 lib 编译的，是不是因为内部大版本之间的 ABI 是否从来未稳定过。
然后弄这个 stackfull 的协程模型是因为 golang 这个语言的野心很大，它希望能把操作系统内核态任务调度这个事情全权交给应用态的 go 调度系统来作，而之前所有的语言 包括 C++ Java C 都是将调度模型交给操作系统提供的线程抽象，这一点上 golang 是一个伟大的进步 配合管道跟非阻塞式 IO 以及 epoll 调用，可以在用户态实现一个无锁且按需调度的调度系统，可以说 go 它是专门为后端服务设计的，当然从语法上来看，目前不支持泛型，我暂时没有加大对 go 这门语言的投入，但是它这个设计理念是好的，那就是带有运行时的语言应该从操作系统那里拿回原本属于我们应用开发人员的调度功能。
这里可以提出两点
1. 管道模型为什么优于锁 monitor ？ 传统操作系统内核提供的监视器锁 存在惊群的问题，这是很难避免的，因为操作系统并不知道你要唤醒多少个线程，当然你也可以指定唤醒的数量，这里就要做到很精细化的锁唤醒操作，例如 Java 里面的 blockingQueue 当队列满了的时候 操作的线程会去 唤醒因为读等待的线程而不是去唤醒因为写等待的线程，当队列空了的时候，当前操作线程就会去唤醒因为写等待的线程而不是去唤醒因为读等待的线程，而之前我所说的这些操作，都需要对并发编程有很高的理解，你才能设计出一个多线程并发且线程安全的队列，这一点对开发人员要求很高，而且从因为监视器锁 Java 的线程会频繁进入内核 开销很大。
但如果使用管道，其实从 golang 调度器来看，当你想从一个管道读数据而挂起的时候，其实 golang 调度器只要把当前线程的几个寄存器换掉就能把对 CPU 的控制权转移到另外一个协程上，这中间无需进入内核调度，而且 golang 还可以做一些优化，把对 CPU 的控制器优先配给需要写这个管道的协程，或者把对同一个管道读写的协程都分配到一个 CPU 上，这样一来 golang 使用管道可以实现完全无锁化的协程之间的通信，但是从编写 golang 的协程代码的人来看，他的大脑负担就会少很多。