Go语言并发模型 P(Processor)

P 是 G 能够在 M 中运行的关键。Go 的运行时系统会适时地让 P 与不同的 M 建立或断开关联,以使 P 中的那些可运行的 G 能够及时获得运行时机,这与操作系统内核在 CPU 之上实时地切换不同的进程或线程的情形类似。

改变单个 Go 程序间接拥有的 P 的最大数量有两种方法。

第一种方法,调用函数 runtime.GOMAXPROCS 并把想要设定的数量作为参数传入。

第二种方法,在Go程序运行前设置环境变量GOMAXPROCS的值。

P 的最大数量实际上是对程序中并发运行的 G 的规模的一种限制。P 的数量即为可运行 G 的队列的数量。一个 G 在被启用后,会先被追加到某个 P 的可运行 G 队列中,以等待运行时机。一个 P 只有与一个 M 关联在一起时,才会使其可运行 G 队列中的 G 有机会运行。不过,设置 P 的最大数量只能限制住 P 的数量,而对 G 和 M 的数量没有任何约束。

当 M 因系统调用而阻塞(更确切地说,是它运行的 G 进入了系统调用)的时候,运行时系统会把该 M 和与之关联的 P 分离开来。这时,如果这个 P 的可运行 G 队列中还有未被运行的 G,那么运行时系统就会找到一个空闲 M,或创建一个新的 M,并与该 P 关联以满足这些 G 的运行需要。因此,M 的数量在很多时候也都会比 P 多。而 G 的数量,一般取决于 Go 程序本身。

在 Go 程序启动之初,引导程序会在初始化调度器时,对P的最大数量进行设置。这里的默认值会与当前 CPU 的总核心数相同。一旦发现环境变量 GOMAXPROCS 的值大于 0,引导程序就会认为我们想要对 P 的最大数量进行设置。它会先检查一下此值的有效性:

如果不大于预设的硬性上限值(256),就认为是有效的,否则就会被这个硬性上限值取代。也就是说,最终的 P 的最大数量值绝不会比硬性上限值大。硬性上限值是 256 的原因是,Go 目前还不能保证在 256 多个 P 同时存在的情形下仍然保持高效。不过,这个硬性上限值并不是永久的,它可能会在未来改变。

注意,虽然 Go 并未对何时调用 runtime.GOMAXPROCS 函数作限制,但是该函数调用的执行会暂时让所有的 P 都脱离运行状态,并试图阻止任何用户级别的 G 的运行。只有在新的 P 最大数量设定完成之后,运行时系统才开始陆续恢复它们。这对于程序的性能是非常大的损耗。所以,你最好只在 Go 程序的 main 函数的最前面调用 runtime.GOMAXPROCS 函数。当然,不在程序中改变 P 的最大数量最好不过,实际上在大多数情况下也无需改变。

确定 P 的最大数量之后,运行时系统会根据这个数值重整全局的 P 列表(runtime. allp)。与全局 M 列表类似,该列表中包含了当前运行时系统创建的所有 P。运行时系统会把这些 P 中的可运行 G 全部取出,并放入调度器的可运行 G 队列中。这是调整全局 P 列表的一个重要前提。被转移的那些 G,会在以后经由调度再次放入某个 P 的可运行 G 队列。

与空闲 M 列表类似,运行时系统中也存在一个调度器的空闲 P 列表(runtime.sched.pidle)。当一个 P 不再与任何 M 关联的时候,运行时系统就会把它放入该列表;而当运行时系统需要一个空闲的 P 关联某个M的话,会从此列表中取出一个。注意,P 进入空闲 P 列表的一个前提条件是它的可运行 G 列表必须为空。例如,在重整全局 P 列表的时候,P 在被清空可运行 G 队列之后,才会被放入空闲 P 列表。

与 M 不同,P 本身是有状态的,可能具有的状态如下:

  • Pidle 此状态表明当前P未与任何M存在关联。
  • Prunning 此状态表明当前P正在与某个M关联。
  • Psyscall 此状态表明当前P中的运行的那个G正在进行系统调用。
  • Pgcstop 此状态表明运行时系统需要停止调度。例如,运行时系统在开始垃圾回收的某些步骤前,就会试图把全局P列表中的所有P都置于此状态。
  • Pdead 此状态表明当前P已经不会再被使用。如果在Go程序运行的过程中,通过调用runtime.GOMAXPROCS函数减少了P的最大数量,那么多余的P就会被运行时系统置于此状态。

P 在创建之初的状态是 Pgcstop,虽然这并不意味着运行时系统要在这时进行垃圾回收。不过,P 处于这一初始状态的时间会非常短暂。在紧接着的初始化之后,运行时系统会将其状态设置为 Pidle,并放入调度器的空闲P列表。

下图描绘了P在各个状态之间进行流转的具体情况:

Go语言并发模型 P(Processor)

可以看到,非 Pdead 状态的 P 都会在运行时系统欲停止调度时被置于 Pgcstop 状态。不过,等到需要重启调度的时候(如垃圾回收结束后),它们并不会被恢复至原有状态,而会被统一地转换为 Pidle 状态。也就是说,它们会被放到同一起跑线上,并公平地接受再次调度。另一方面,非 Pgcstop 状态的 P 都可能因全局 P 列表的缩小而被认为是多余的,并被置于 Pdead 状态。不过,我们并不用担心其中的 G 会失去归宿。因为,在 P 被转换为 Pdead 状态之前,其可运行 G 队列中的 G 都会被转移到调度器的可运行 G 队列,而它的自由 G 列表中的 G 也都会被转移到调度器的自由 G 列表中。

正如前面所述,每个 P 中除了一个可运行 G 队列外,还都包含一个自由 G 列表。这个列表中包含了一些已经运行完成的 G。随着运行完成的 G 的增多,该列表可能会很长。如果它增长到一定程度,运行时系统就会把其中的部分 G 转移到调度器的自由 G 列表中。另一方面,当使用 go 语句启用一个 G 的时候,运行时系统会先试图从相应 P 的自由 G 列表中获取一个现成的 G,来封装这个 go 语句携带的函数(也称go函数),仅当获取不到这样一个 G 的时候才有可能创建一个新的G。考虑到相应 P 的自由 G 列表为空而获取不到自由 G 的情况,运行时系统会在发现其中的自由 G 太少时,预先尝试从调度器的自由 G 列表中转移过来一些 G。如此一来,只有在调度器的自由 G 列表也弹尽粮绝的时候,才会有新的 G 被创建。这在很大程度上提高了 G 的复用率。

在P的结构中,可运行 G 队列和自由 G 列表是最重要的两个成员。至少对于 Go 语言的使用者来说是这样。它们间接地体现了运行时系统对 G 的调度情况。

下一章:Golang Context 是什么

Go 1.7 标准库引入 context 包,中文翻译为 “上下文”,准确说它是 goroutine 的上下文,它包含 goroutine 的运行状态、环境、现场等信息。context 主要用来在 go ...