sysmon是Go运行时中不依赖P、独立运行于M上的后台监控协程，负责轮询检查网络事件、抢占长时间运行的G、触发GC及回收空闲P等，但不直接唤醒M——它仅通过notewakeup等机制通知调度器，由OS系统调用最终完成唤醒。
sysmon 是什么，它真能“唤醒 M”吗
不能。sysmon 本身不负责唤醒工作线程（M），它只是操作系统级的监控协程，运行在独立的系统线程上，定期轮询检查全局状态（比如长时间未调度的 G、网络轮询器超时、垃圾回收时机等）。它触发的是调度器层面的干预动作，比如调用 notewakeup(&m.park) 或向某个 note 发送信号，但真正让 M 从休眠中恢复执行的，是底层的 futex（Linux）或 WaitForMultipleObjects（Windows）等系统调用返回 —— 而这依赖于 M 当初是用什么机制休眠的。
常见误解是把 sysmon 当成“M 的闹钟”，其实它更像一个“巡检员”，发现异常后通知调度器，再由调度器决定是否需要唤醒某个 M（例如：有新 G 就绪、netpoll 有事件、或者 M 被挂起太久需强制抢断）。
M 休眠时到底在等什么
Go 运行时中，M 进入休眠主要有两类场景，等待对象完全不同：
- 空闲 M 等待新 G：调用
notesleep(&m.park)，底层阻塞在futex(wait)上，等待其他 goroutine（如 scheduler 或 sysmon）调用notewakeup(&m.park) - 执行阻塞系统调用的 M（如
read、accept）：此时 M 已脱离 Go 调度器管理，直接交由 OS 调度；它不通过note休眠，而是被 OS 挂起，唤醒完全由系统调用返回触发
注意：sysmon 只会对第一类（parked M）做主动干预（比如检测到 M 空闲超 10ms 就尝试唤醒一个来检查是否有积压 G），对第二类它基本不插手 —— 那是 netpoller 和 entersyscall/exitsyscall 机制的事。
为什么有时 M 唤醒后立刻又 park 了
这是调度器负载均衡和空闲 M 回收策略导致的典型现象，不是 bug。关键点在于：
-
sysmon唤醒 parked M 后，该 M 会立即进入scheduler()主循环，尝试从全局队列或 P 的本地队列偷取 G - 如果此时没有可运行的 G（队列为空、GC 正在暂停调度、或所有 G 都在 syscall 中），M 会再次调用
notesleep(&m.park)进入休眠 - Go 默认限制最大空闲 M 数量（由
runtime.GOMAXPROCS和活跃 P 数动态影响），多余的 parked M 可能被sysmon定期清理（调用dropm()归还 OS 线程）
所以你看到“唤醒 → 检查 → 再 park”，往往说明当前确实没活干。这不是信号失效，而是调度器在精准节制资源。
调试 parked M 和 sysmon 行为的实用方法
想确认 M 是否被 sysmon 干预过，或排查唤醒延迟问题，别只看 pprof，要结合运行时 trace 和日志：
- 启动时加
GODEBUG=schedtrace=1000：每秒打印调度器摘要，观察Midle（空闲 M 数）、Mspinning（自旋中 M 数）变化节奏 - 用
go tool trace查看Proc Status视图，找M状态从Idle→Running→Idle的完整周期，比对时间戳与sysmon活动标记 - 注意
runtime_pollWait类阻塞调用不会走note机制，它们的“唤醒”实际由netpoll通过epoll_wait返回驱动，和sysmon无关 —— 别误以为sysmon慢就等于网络 I/O 延迟高
真正容易被忽略的是：M 的 park/unpark 不是原子操作，中间可能穿插 GC STW、抢占点检查、甚至其他 M 的并发修改。看单次 trace 很难定位，得抓一段时间窗口里的模式。
