sysmon 后台监控线程做了什么
在 runtime.main() 函数中，执行 runtime_init() 前，会启动一个 sysmon 的监控线程，执行后台监控任务：
systemstack(func() {
// 创建监控线程，该线程独立于调度器，不需要跟 p 关联即可运行
newm(sysmon, nil)
})sysmon 函数不依赖 P 直接执行，通过 newm 函数创建一个工作线程：
func newm(fn func(), _p_ *p) {
// 创建 m 对象
mp := allocm(_p_, fn)
// 暂存 m
mp.nextp.set(_p_)
mp.sigmask = initSigmask
// ……………………
execLock.rlock() // Prevent process clone.
// 创建系统线程
newosproc(mp, unsafe.Pointer(mp.g0.stack.hi))
execLock.runlock()
}先调用 allocm 在堆上创建一个 m，接着调用 newosproc 函数启动一个工作线程：
核心就是调用 clone 函数创建系统线程，新线程从 mstart 函数开始执行。clone 函数由汇编语言实现：
先是为 clone 系统调用准备参数，参数通过寄存器传递。第一个参数指定内核创建线程时的选项，第二个参数指定新线程应该使用的栈，这两个参数都是通过 newosproc 函数传递进来的。
接着将 m, g0, fn 分别保存到寄存器中，待子线程创建好后再拿出来使用。因为这些参数此时是在父线程的栈上，若不保存到寄存器中，子线程就取不出来了。
这个几个参数保存在父线程的寄存器中，创建子线程时，操作系统内核会把父线程所有的寄存器帮我们复制一份给子线程，所以当子线程开始运行时就能拿到父线程保存在寄存器中的值，从而拿到这几个参数。
之后，调用 clone 系统调用，内核帮我们创建出了一个子线程。相当于原来的一个执行分支现在变成了两个执行分支，于是会有两个返回。这和著名的 fork 系统调用类似，根据返回值来判断现在是处于父线程还是子线程。
如果是父线程，就直接返回了。如果是子线程，接着还要执行一堆操作，例如设置 tls，设置 m.procid 等等。
最后执行 mstart 函数，这是在 newosproc 函数传递进来的。mstart 函数再调用 mstart1，在 mstart1 里会执行这一行：
之前我们在讲初始化的时候，这里的 fn 是空，会跳过的。但在这里，fn 就是最开始在 runtime.main 里设置的 sysmon 函数，因此这里会执行 sysmon，而它又是一个无限循环，永不返回。
所以，这里不会执行到 mstart1 函数后面的 schedule 函数，也就不会进入 schedule 循环。因此这是一个不用和 p 结合的 m，它直接在后台执行，默默地执行监控任务。
接下来，我们就来看 sysmon 函数到底做了什么？
sysmon执行一个无限循环，一开始每次循环休眠 20us，之后（1 ms 后）每次休眠时间倍增，最终每一轮都会休眠 10ms。
sysmon中会进行 netpool（获取 fd 事件）、retake（抢占）、forcegc（按时间强制执行 gc），scavenge heap（释放自由列表中多余的项减少内存占用）等处理。
和调度相关的，我们只关心 retake 函数：
从代码来看，主要会对处于 _Psyscall 和 _Prunning 状态的 p 进行抢占。
抢占进行系统调用的 P
当 P 处于 _Psyscall 状态时，表明对应的 goroutine 正在进行系统调用。如果抢占 p，需要满足几个条件：
p 的本地运行队列里面有等待运行的 goroutine。这时 p 绑定的 g 正在进行系统调用，无法去执行其他的 g，因此需要接管 p 来执行其他的 g。
没有“无所事事”的 p。
sched.nmspinning和sched.npidle都为 0，这就意味着没有“找工作”的 m，也没有空闲的 p，大家都在“忙”，可能有很多工作要做。因此要抢占当前的 p，让它来承担一部分工作。从上一次监控线程观察到 p 对应的 m 处于系统调用之中到现在已经超过 10 毫秒。这说明系统调用所花费的时间较长，需要对其进行抢占，以此来使得
retake函数返回值不为 0，这样，会保持 sysmon 线程 20 us 的检查周期，提高 sysmon 监控的实时性。
注意，原代码是用的三个与条件，三者都要满足才会执行下面的 continue，也就是不进行抢占。因此要想进行抢占的话，只需要三个条件有一个不满足就行了。于是就有了上述三种情况。
确定要抢占当前 p 后，先使用原子操作将 p 的状态修改为 _Pidle，最后调用 handoffp 进行抢占。
handoffp 再次进行场景判断，以调用 startm 启动一个工作线程来绑定 p，使得整体工作继续推进。
当 p 的本地运行队列或全局运行队列里面有待运行的 goroutine，说明还有很多工作要做，调用 startm(_p_, false) 启动一个 m 来结合 p，继续工作。
当除了当前的 p 外，其他所有的 p 都在运行 goroutine，说明天下太平，每个人都有自己的事做，唯独自己没有。为了全局更快地完成工作，需要启动一个 m，且要使得 m 处于自旋状态，和 p 结合之后，尽快找到工作。
最后，如果实在没有工作要处理，就将 p 放入全局空闲队列里。
我们接着来看 startm 函数都做了些什么：
首先处理 p 为空的情况，直接从全局空闲 p 队列里找，如果没找到，则直接返回。如果设置了 spinning 为 true 的话，还需要还原全局的处于自旋状态的 m 的数值：&sched.nmspinning 。
搞定了 p，接下来看 m。先调用 mget 函数从全局空闲的 m 队列里获取一个 m，如果没找到 m，则要调用 newm 新创建一个 m，并且如果设置了 spinning 为 true 的话，先要设置好 mstartfn：
这样，启动 m 后，在 mstart1 函数里，进入 schedule 循环前，执行 mstartfn 函数，使得 m 处于自旋状态。
接下来是正常情况下（找到了 p 和 m）的处理：
设置 nextp 为找到的 p，调用 notewakeup 唤醒 m。之前我们讲 findrunnable 函数的时候，对于最后没有找到工作的 m，我们调用 notesleep(&_g_.m.park)，使得 m 进入睡眠状态。现在终于有工作了，需要老将出山，将其唤醒：
notewakeup函数首先使用atomic.Xchg设置note.key值为 1，这是为了使被唤醒的线程可以通过查看该值是否等于 1 来确定是被其它线程唤醒还是意外从睡眠中苏醒了过来。如果该值为 1 则表示是被唤醒的，可以继续工作，但如果该值为 0 则表示是意外苏醒，需要再次进入睡眠。
调用 futexwakeup 来唤醒工作线程，它和 futexsleep 是相对的。
futex 由汇编语言实现，前面已经分析过，这里就不重复了。主要内容就是先准备好参数，然后进行系统调用，由内核唤醒线程。
内核在完成唤醒工作之后当前工作线程从内核返回到 futex 函数继续执行 SYSCALL 指令之后的代码并按函数调用链原路返回，继续执行其它代码。
而被唤醒的工作线程则由内核负责在适当的时候调度到 CPU 上运行。
抢占长时间运行的 P
我们知道，Go scheduler 采用的是一种称为协作式的抢占式调度，就是说并不强制调度，大家保持协作关系，互相信任。对于长时间运行的 P，或者说绑定在 P 上的长时间运行的 goroutine，sysmon 会检测到这种情况，然后设置一些标志，表示 goroutine 自己让出 CPU 的执行权，给其他 goroutine 一些机会。
接下来我们就来分析当 P 处于 _Prunning 状态的情况。sysmon 扫描每个 p 时，都会记录下当前调度器调度的次数和当前时间，数据记录在结构体：
前面两个字段记录调度器调度的次数和时间，后面两个字段记录系统调用的次数和时间。
在下一次扫描时，对比 sysmon 记录下的 p 的调度次数和时间，与当前 p 自己记录下的调度次数和时间对比，如果一致。说明 P 在这一段时间内一直在运行同一个 goroutine。那就来计算一下运行时间是否太长了。
如果发现运行时间超过了 10 ms，则要调用 preemptone(_p_) 发起抢占的请求：
基本上只是将 stackguard0 设置了一个很大的值，而检查 stackguard0 的地方在函数调用前的一段汇编代码里进行。
举一个简单的例子：
执行命令：
得到汇编代码：
以前看这段代码的时候会直接跳过前面的几行代码，看不懂。这次能看懂了！所以，那些暂时看不懂的，先放一放，没关系，让子弹飞一会儿，很多东西回过头再来看就会豁然开朗，这就是一个很好的例子。
将本地存储 tls 保存到 CX 寄存器中，（TLS）表示它所关联的 g，这里就是前面所讲到的 main gouroutine。
比较 SP 寄存器（代表当前 main goroutine 的栈顶寄存器）和 16(CX)，我们看下 g 结构体：
对象 g 的第一个字段是 stack 结构体：
共 16 字节。而 16(CX) 表示 g 对象的第 16 个字节，跳过了 g 的第一个字段，也就是 g.stackguard0 字段。
如果 SP 小于 g.stackguard0，这是必然的，因为前面已经把 g.stackguard0 设置成了一个非常大的值，因此跳转到了 113 行。
调用 runtime.morestack_noctxt 函数：
直接跳转到 morestack 函数：
主要做的工作就是将当前 goroutine，也就是 main goroutine 的和调度相关的信息保存到 g.sched 中，以便在调度到它执行时，可以恢复。
最后，将 g0 的地址保存到 tls 本地存储，并且切到 g0 栈执行之后的代码。继续调用 newstack 函数：
去掉了很多暂时还看不懂的地方，留到后面再研究。只关注有关抢占相关的。第一次判断 preempt 标志是 true 时，检查了 g 的状态，发现不能抢占，例如它所绑定的 P 的状态不是 _Prunning，那就恢复它的 stackguard0 字段，下次就不会走这一套流程了。然后，调用 gogo(&gp.sched) 继续执行当前的 goroutine。
中间又处理了很多判断流程，再次判断 preempt 标志是 true 时，调用 gopreempt_m(gp) 将 gp 切换出去。
最终调用 goschedImpl 函数：
将 gp 的状态改为 _Grunnable，放入全局可运行队列，等待下次有 m 来全局队列找工作时才能继续运行，毕竟你已经运行这么长时间了，给别人一点机会嘛。
最后，调用 schedule() 函数进入新一轮的调度循环，会找出一个 goroutine 来运行，永不返回。
这样，关于 sysmon 线程在关于调度这块到底做了啥，我们已经回答完了。总结一下：
抢占处于系统调用的 P，让其他 m 接管它，以运行其他的 goroutine。
将运行时间过长的 goroutine 调度出去，给其他 goroutine 运行的机会。
Last updated
Was this helpful?