深度剖析 Goroutine

小伙伴们有没有觉得学习Golang很有意思？有意思就对了！今天就给大家带来《深度剖析 Goroutine》，以下内容将会涉及到，若是在学习中对其中部分知识点有疑问，或许看了本文就能帮到你！

我试图理解 golang 架构以及“轻量级线程”的含义。我已经读过一些内容，但想提出问题来澄清。

如果我说“go”关键字只是将以下函数放入内部线程池的队列中，但对于用户来说，它看起来像是创建线程，我说得对吗？

正确答案

这是从 Go FAQ 复制的：

这里缺少的是线程的定义。如果我们求助于 Wikipedia，我们会发现：

但这只是对 goroutine 的描述。这里的问题是，单词线程往往指的是内核线程和/或用户线程（两者都在同一维基百科页面上定义）并且这些线程比 goroutine 线程更重。这让我们回到了这一点：

开门见山，这意味着“比操作系统提供的更轻”。这就是它的全部含义。有操作系统提供的线程（在运行 Go 的多个操作系统上），但它们通常会做太多事情并且切换成本太高，因此 Go 提供了自己的语言级线程，称为“goroutines” “ 轻得多。

来自评论：

这是一个实现细节，涉及操作系统提供的内核线程的另一个方面：

当前的 Go 运行时 goroutine / 线程 / 处理器调度程序（请参阅 What is relationship between goroutine and thread in kernel and user state 并注意，不仅仅是当前的实现）预测某些系统调用将阻塞，并确保分配该调用系统调用它自己的操作系统级内核线程（另请参见 JimB's comment）。这些线程不计入 GOMAXPROCS 设置。事实上，有时这是一个问题，因为 Go 运行时可能会尝试分出比操作系统允许的更多的线程：如果这里有一个系统调用线程池可能会很好（尽管也存在明显的问题）与此）。

因此，当前运行时创建最多 GOMAXPROCS 内核样式操作系统级线程，并使用这些线程将最多多个 goroutine 复用到 CPU 上，但创建额外的内核样式操作系统-level 线程 任何时候都可以。正如 the blog post linked in the question above 所指出的，P 实体充当队列，在每个处理器的基础上保存 goroutine (Gs)，以进行本地化缓存查找（请记住，在某些系统上，尤其是 NUMA 的系统上，“跨”CPU 进行访问的成本很高：调度程序是仍然愿意这样做，但不会太频繁地这样做，因为“太频繁”的某些定义）。

当前调度程序的早期版本需要显式yield (runtime.Gosched()) 调用或各种其他运行时操作来导致从当前 goroutine 切换到其他 goroutine。例如，请参见 What exactly does runtime.Gosched do?。在 Go 1.14 中，一些操作系统提供自动 goroutine 抢占；见Will Go's scheduler yield control from one goroutine to another for CPU-intensive work?

本篇关于《深度剖析 Goroutine》的介绍就到此结束啦，但是学无止境，想要了解学习更多关于Golang的相关知识，请关注golang学习网公众号！