golang goroutine 会耗尽系统资源吗
发布网友
发布时间：2022-04-23 08:15
共2个回答
懂视网
时间：2022-04-18 19:56
背景
最近在学习MIT的分布式课程6.824的过程中，使用Go实现Raft协议时遇到了一些问题。分享出来供大家参考学习，下面话不多说了，来一起看看详细的介绍吧。
参见如下代码：
其中，peers切片的长度为3，因此最高下标为2，在非并行编程中代码中的for-loop应该是很直观的，我当时并没有意识到有什么问题。可是在调试过程中，一直在报 index out of bounds 错误。调试信息显示i的值为3，当时就一直想不明白循环条件明明是 i < 2，怎么会变成3呢。
分析
虽然不明白发生了什么，但知道应该是循环中引入的 goroutine 导致的。经过Google，发现Go的wiki中就有一个页面 Common Mistake - Using goroutines on loop iterator variables 专门提到了这个问题，看来真的是很 common 啊，笑哭~
初学者经常会使用如下代码来并行处理数据：
或者使用闭包（closure）：
这里的问题在于 val 实际上是一个遍历了切片中所有数据的单一变量。由于闭包只是绑定到这个 val 变量上，因此极有可能上面的代码的运行结果是所有 goroutine 都输出了切片的最后一个元素。这是因为很有可能当 for-loop 执行完之后 goroutine 才开始执行，这个时候 val 的值指向切片中最后一个元素。
The val variable in the above loops is actually a single variable that takes on the value of each slice element. Because the closures are all only bound to that one variable, there is a very good chance that when you run this code you will see the last element printed for every iteration instead of each value in sequence, because the goroutines will probably not begin executing until after the loop.
解决方法
以上代码正确的写法为：
在这里将 val 作为一个参数传入 goroutine 中，每个 val 都会被计算并保存到 goroutine 的栈中，从而得到预期的结果。
另一种方法是在循环内定义新的变量，由于在循环内定义的变量在循环遍历的过程中是不共享的，因此也可以达到同样的效果：
对于文章开头提到的那个问题，最简单的解决方案就是在循环内加一个临时变量，并将后面 goroutine 内的 i 都替换为这个临时变量即可：
总结
热心网友
时间：2022-04-18 17:04
Go runtime的调度器：在了解Go的运行时的scheler之前，需要先了解为什么需要它，因为我们可能会想，OS内核不是已经有一个线程scheler了嘛？熟悉POSIX API的人都知道，POSIX的方案在很大程度上是对Unix process进场模型的一个逻辑描述和扩展，两者有很多相似的地方。 Thread有自己的信号掩码，CPU affinity等。但是很多特征对于Go程序来说都是累赘。 尤其是context上下文切换的耗时。另一个原因是Go的垃圾回收需要所有的goroutine停止，使得内存在一个一致的状态。垃圾回收的时间点是不确定的，如果依靠OS自身的scheler来调度，那么会有大量的线程需要停止工作。 单独的开发一个GO得调度器，可以是其知道在什么时候内存状态是一致的，也就是说，当开始垃圾回收时，运行时只需要为当时正在CPU核上运行的那个线程等待即可，而不是等待所有的线程。用户空间线程和内核空间线程之间的映射关系有：N:1,1:1和M:NN:1是说，多个（N）用户线程始终在一个内核线程上跑，context上下文切换确实很快，但是无法真正的利用多核。1：1是说，一个用户线程就只在一个内核线程上跑，这时可以利用多核，但是上下文switch很慢。M:N是说， 多个goroutine在多个内核线程上跑，这个看似可以集齐上面两者的优势，但是无疑增加了调度的难度。
