一道经常考的面试题

“每个goroutine生成后，在P的本地G队列未满的时候，是依次加入到P的本地G队列里的” 这句话中的P、G含义？

P是逻辑处理器P0 G是程序中开的协程吧？

9 为什么是第一个输出的，我之前有专门有给星球的用户写文章讲解过。

runtime2.go 中关于 p 的定义： 其中 runnext 指针决定了下一个要运行的 g，根据英文的注释大致意思是说：

• 1 . 如果 runnext 不为空且是就绪的，那么应该优先运行该 runnext 指向的 g 而不是运行队列中到达运行时间的 g。
• 2 . 此时要被运行的 g 将继承当前 g 剩余的时间片继续执行。
• 3 . 之所以这样做是为了消除将最后的 g 添加到队列末尾导致的潜在的调度延迟。

所以当设置 runtime.GOMAXPROCS(1) 时，此时只有一个 P，创建的 g 依次加入 P， 当最后一个即 i==9 时，加入的最后 一个 g 将会继承当前主 goroutinue 的剩余时间片继续执行，所以会先输出 9， 之后再依次执行 P 队列中其它的 g。

个人看源码找到的答案，如有错误请立刻指出。

type p struct {
    lock mutex

    id          int32
    status      uint32 // one of pidle/prunning/...
    link        puintptr
    schedtick   uint32     // incremented on every scheduler call
    syscalltick uint32     // incremented on every system call
    sysmontick  sysmontick // last tick observed by sysmon
    m           muintptr   // back-link to associated m (nil if idle)
    mcache      *mcache
    racectx     uintptr

    deferpool    [5][]*_defer // pool of available defer structs of different sizes (see panic.go)
    deferpoolbuf [5][32]*_defer

    // Cache of goroutine ids, amortizes accesses to runtime·sched.goidgen.
    goidcache    uint64
    goidcacheend uint64

    // Queue of runnable goroutines. Accessed without lock.
    runqhead uint32
    runqtail uint32
    runq     [256]guintptr
    // runnext, if non-nil, is a runnable G that was ready'd by
    // the current G and should be run next instead of what's in
    // runq if there's time remaining in the running G's time
    // slice. It will inherit the time left in the current time
    // slice. If a set of goroutines is locked in a
    // communicate-and-wait pattern, this schedules that set as a
    // unit and eliminates the (potentially large) scheduling
    // latency that otherwise arises from adding the ready'd
    // goroutines to the end of the run queue.
    runnext guintptr
        ...
}

最后的P 是 放在 local queue 的头部的，所以第一个执行

从执行角度看的确可以看作是放在了 runq 的头部

第一个循环，如果把10改为100或者1000，会有比较大的概率出现你的预期结果。

func main() {
    runtime.GOMAXPROCS(1)
    var wg sync.WaitGroup
    for i := 0; i < 1000; i++ {
        wg.Add(1)

        go func(p int) {
            fmt.Println(p)
            wg.Done()
        }(i)

    }
    wg.Wait()
}

将循环改为 1000 后,输出也是固定的,但是顺序很乱,求大佬解惑

//我的输出最后如下
75
76
77
131
78
79
80
81
...
768
769
770
771
901

猜测 G 队列有大小,所以出现一段有顺序的,然后另一段有顺序的.但是其中又有 77 131 78 这种就奇怪了 验证中...

加个chan控制下

func main() {
    var wg sync.WaitGroup
    ch  := make(chan struct{})
    for i := 0; i < 10; i++ {
        wg.Add(1)
        go func(n int) {
            <- ch
            fmt.Println(n)
            wg.Done()
        }(i)
        ch <- struct{}{}
    }
    close(ch)
    wg.Wait()
}

是go.runtime的知识，MPG。 也看是否有启动过goroutine。第一次运行估计都是10；

掘坟 https://zhuanlan.zhihu.com/p/413218471 为后人植树 重点在runnext