go中的goroutine

白小白的小白

已于 2022-11-08 15:22:44 修改

阅读量488

点赞数

分类专栏： go 文章标签： java 分布式 jvm

于 2022-08-31 11:04:48 首次发布

本文链接：https://blog.csdn.net/qq_42874635/article/details/126618954

版权

go 专栏收录该内容

36 篇文章 1 订阅

订阅专栏

go中的Goroutine

概念

Goroutine可以理解为一种Go语言的协程（轻量级线程），是Go支持高并发的基础，属于用户态的线程，由Go runtime管理而不是操作系统

创建

通过go关键字调用底层函数runtime.newproc()创建一个goroutine
当调用该函数之后，goroutine会被设置成runnable状态

func main() {
   go func() {
    fmt.Println("func routine")
   }()
   fmt.Println("main goroutine")
}

创建好的这个goroutine会新建一个自己的栈空间，同时在G的sched中维护栈地址与程序计数器这些信息。

每个 G 在被创建之后，都会被优先放入到本地队列中，如果本地队列已经满了，就会被放入到全局队列中。

线程和goroutine的区别

在这里插入图片描述

Go goroutine泄露的场景

泄露原因

Goroutine 内进行channel/mutex 等读写操作被一直阻塞。
Goroutine 内的业务逻辑进入死循环，资源一直无法释放。
Goroutine 内的业务逻辑进入长时间等待，有不断新增的 Goroutine 进入等待

如何排查

单个函数：调用 runtime.NumGoroutine 方法来打印执行代码前后Goroutine 的运行数量，进行前后比较，就能知道有没有泄露了
生产/测试环境：使用PProf实时监测Goroutine的数量

用什么方法控制goroutine并发的数量

有缓冲的channel，利用缓冲满时发送阻塞的特性
无缓冲的channel，任务发送和执行分离，指定消费者并发协程数

go中的调度模式

go中早先的GM调度模式

在这里插入图片描述

GM调度存在的问题

全局队列的锁竞争，当 M 从全局队列中添加或者获取 G 的时候，都需要获取队列锁，导致激烈的锁竞争
M 转移 G 增加额外开销，当 M1 在执行 G1 的时候， M1 创建了 G2，为了继续执行 G1，需要把 G2 保存到全局队列中，无法保证G2是被M1处理。因为 M1 原本就保存了 G2 的信息，所以 G2 最好是在 M1 上执行，这样的话也不需要转移G到全局队列和线程上下文切换
线程使用效率不能最大化，没有work-stealing 和hand-off 机制

计算机科学领域的任何问题都可以通过增加一个间接的中间层来解决，为了解决这一的问题 go 从 1.1 版本引入P，在运行时系统的时候加入 P 对象，让 P 去管理这个 G 对象，M 想要运行 G，必须绑定 P，才能运行 P 所管理的 G

GPM模式的设计策略

go中的GMP调度模式图：

在这里插入图片描述
上图中M开头的代表线程，P代表调度器，G代表协程，每一个调度器都有一个本地队列，里面存放的是待执行的G协程，而全局队列里面存放的也是待执行的G协程，但是只有所有的本地队列满了以后才会往全局队列中放G协程

复用线程

work stealing机制

还是以上图为例，假设有二个线程，M0 M1 M0下的调度器的本地队列有多个携程，而M1下的调度器的本地队列也有多个协程，但是M1下的协程执行完了，而M0下的协程还有很多，这个M1就会从M0下拿取一些协程去执行(先去全局队列中，如果没有全局队列再去M0)，从而避免了资源浪费，这就work stealing机制

hand off机制

还是以上图为例，假设有二个线程，M0 M1 M0下的调度器的本地队列P1有多个携程，而M1下的调度器的本地队列P2也有多个协程，但是M0下正在执行的携程G1有大量的读取操作，导致M0堵塞，这样的话，调度器会再创建或者唤醒一个线程M3，将M1下P2的G2 G3等转移过去执行(就是把P1打包带走，除了G1)，而G1与线程M0绑定到一起堵塞，堵塞完毕后G1重新回到其他本地队列中执行，而M1此时则睡眠或者销毁，这就是hand off机制