【Golang】Go的并发和并行性解释。谁说Go不是并行语言？

偶然发现百度上有很多"师出同门"的"go是并发语言，而不是并行语言"的说法。让我顿感奇怪，"并行"说白了就是对CPU多核的利用，这年头不能利用多核的编译语言还有的混？而且还混的这么好？并且go是出了名的高并发能力强，GPM模型也是为了实现并行，怎么可能会不是并行语言呢。于是进行了一番调查。。。

最终我认为起点大概率是在"Rob Pike"(Go作者之一)于2012年发表的一场演讲，名为"并发不是并行"。之后则被某些标题党曲解为"go是并发语言，而不是并行语言"，百度上可以搜到很多这个说法(CV大法，师出同门)，不过在Google上通过英文搜索则很少有这个说法。

像这种"以讹传讹"的现象以前也碰到过很多次了，其实深入推敲一下就比较容易发现矛盾点。在这里希望大家在传递知识的时候保持疑问心和严谨性，避免让错误的内容得到传播。当然，假如我的调查有误，这场演讲也是提供对golang并发和并行性讨论的权威指南，具有很强的参考价值。

go.dev/talks上保存了此次演讲的幻灯片(通过左右箭头键进行导航)，我们可以查看它以获得此次演讲的内容。

简单说，Rob Pike 用很多"地鼠工人"(gopher)把一个"烧书"任务进行了循序渐进的并发设计，不同的并发设计支持不同的并行方式。并发是一种通过将程序分成可以独立执行的片段来构建程序的方法，并发设计就是分解处理过程。例如：

• 这是一个三只地鼠协同工作的设计，每个地鼠都是一个独立执行的一段程序。
  

• 这是更复杂的设计，设计了两条工作线，每条线上还加入了暂存堆，16只地鼠在努力工作。
  

实际上地鼠就是CPU，更准确地说是goroutine，goroutine会根据需要复用到操作系统线程上(GPM模型)，以实现并行。
即便一次(同一时间)只有一只地鼠在工作，整个程序仍然是并发的(这是设计结构上的)，只不过不是并行的。并发而不并行就是说在单核CPU中，程序会自动地让每个地鼠交替工作，以"同时处理"多个子任务从而完成整个任务；但一旦并行(多核CPU)，多个地鼠(多个CPU核心)就会"同时工作"，更快地完成整个任务。

最终，幻灯片给出了并发和并行的关系结论：

• 并发性很强大。
• 并发不是并行。
• 并发实现了并行。
• 并发使并行性变得容易。

从这里可以看出，Rob Pike 表达的主要思想是：并发不是并行，但并发设计对于实现并行来说是重要/必要的，并行离不开并发。

在go中，goroutine就是用来进行并发设计，然后goroutine会根据情况自动的复用到操作系统线程(GPM模型)，以实现并行。
(ps: channel则是用来协调goroutine执行的手段)