Go并发编程-线程模型（G）

G（Go代码片段）
一个G就代表一个goroutine，也与go函数相对应。作为编程人员，我们只是使用go语句向Go的运行时系统提交了一个并发任务，而Go的运行时系统则会按照我们的要求并发地执行它。

Go的编译器会把go语句变成对内部函数newproc的调用，并把go函数及其参数都作为参数传递给这个函数。其实它并不神秘，只是一种递送并发任务的方法而已。

运行时系统在接到这样一个调用之后，会先检查go函数及其参数的合法性，然后试图从本地P的自由G列表和调度器的自由G列表获取可用的G，如果没有获取到，就新建一个G。

与M和P相同，运行时系统也持有一个G的全局列表（runtime.allgs）。新建的G会在第一时间被加入该列表。类似地，这个全局列表的主要作用是：集中存放当前运行时系统中的所有G的指针。
无论用于封装当前这个go函数的G是否是新创建的，运行时系统都会对它进行一次初始化，包括关联go函数以及设置该G的状态和ID等步骤。在初始化完成后，这个G会立即被存储到本地P的runnext字段中；该字段用于存放新鲜出炉的G，以求更早地运行它。如果这时runnext字段已存有一个G，那么这个已有的G就会被“踢到”该P的可运行G队列的末尾。如果该队列已满，那么这个G就只能追加到调度器的可运行G队列中了。

在特定情况下，一旦新启用的G被存于某地，调度就会立即进行以使该G尽早被运行。不过，即使这里不立即调度，我们也无需担心，因为运行时系统总是在为及时运行每个G忙碌着。

每一个G都会由运行时系统根据其实际状况设置不同的状态，其主要状态如下。

• Gidle: 表示当前G刚被新分配，但还未初始化。
• Grunnable: 表示当前G正在可运行队列中等待运行。
• Grunning: 表示当前G正在运行。
• Gsyscall: 表示当前G正在执行某个系统调用。
• Gwaiting: 表示当前G正在阻塞。
• Gdead: 表示当前G正在闲置。
• Gcopystack: 表示当前G的栈正被移动，移动的原因可能是栈的扩展或收缩。

除了上述状态，还有一个称为Gscan的状态。不过这个状态并不能独立存在，而是组合状态的一部分。比如，Gscan与Grunnable组合成Gscanrunnable状态，代表当前G正等待运行，同时它的栈正被扫描，扫描的原因一般是GC（垃圾回收）任务的执行。又比如，Gscan与Grunning组合成Gscanrunning状态，表示正处于Grunning状态的当前G的栈要被GC扫描时的一个短暂时刻。

之前讲过，在运行时系统想用一个G封装go函数的时候，会先对这个G进行初始化。一旦该G准备就绪，其状态就会被设置成Grunnable。也就是说，一个G真正开始被使用是在其状态设置为Grunnable之后。下图展示了G在其生命周期内的状态流转情况。

G的状态转化图

一个G在运行的过程中，是否会等待某个事件以及会等待什么样的事件，完全由其封装的go函数决定。例如，如果这个函数中包含对通道值的操作，那么在执行到对应代码的时候，这个G就有可能进入Gwaiting状态。这可能是在等待从通道类型值中接收值，也可能是在等待向通道类型值发送值。又例如，涉及网络I/O的时候也会导致相应的G进入Gwaiting状态。此外，操纵定时器（time.Timer）和调用time.Sleep函数同样会造成相应G的等待。在事件到来之后，G会被“唤醒”并被转换至Grunnable状态。待时机到来时，它会被再次运行。

G在退出系统调用时的状态转换要比上述情况复杂一些。运行时系统会先尝试直接运行这个G，仅当无法直接运行的时候，才会把它转换为Grunnable状态并放入调度器的自由G列表中。显然，对这样一个G来说，在其退出系统调用之时就立即被恢复运行再好不过了。运行时系统当然会为此做出一些努力，不过即使努力失败了，该G也还是会在实时的调度过程中被发现并运行。

最后，值得一提的是，进入死亡状态（Gdead）的G是可以重新初始化并使用的。相比之下，P在进入死亡状态（Pdead）之后，就只能面临销毁的结局。由此也可以说明Gdead状态与Pdead状态所表达的含义截然不同。处于Gdead状态的G会被放入本地P或调度器的自由G列表，这是它们被重用的前提条件。

相关链接：
Go并发编程-线程模型
Go并发编程-线程模型（M）
Go并发编程-线程模型（P）
Go并发编程-线程模型（G）

参考资料：
https://www.ituring.com.cn/book/tupubarticle/16048