go 高级工程师需实操验证 netpoll 与调度协同机制：goroutine 卡在 io wait 时 m 实际在 epoll_wait 中高效轮询，真正阻塞的是未被唤醒的业务 goroutine，而非系统瓶颈；需结合 pprof、strace、go tool trace 定位真实问题。
go 高级工程师岗位中，runtime 和 netpoll 相关问题不是考概念复述，而是看是否真在线上压测、排障、调优时动过手。没碰过 pprof 看协程堆积、没改过 gomaxprocs 观察调度抖动、没在 strace 里盯过 epoll_wait 调用的，答得再“标准”也容易被追问露馅。
为什么 goroutine 会卡住，但 strace 显示 M 在 epoll_wait？
这是 runtime 与 netpoll 协同机制最常被误读的一点：goroutine 阻塞 ≠ M 阻塞。当一个 goroutine 因网络 I/O（比如 conn.Read()）挂起时，它会被从 P 的本地队列移出，加入 netpoller 的等待列表，而对应的 M 不会阻塞，而是立即去执行其他可运行的 G。
常见错误现象：
- pprof goroutine profile 显示大量
net.(*netFD).Read状态为IO wait，但 CPU 使用率很低 - strace -p 看到 M 长时间停在
epoll_wait，误以为是系统瓶颈
真实原因：netpoller 正常工作，M 在高效轮询就绪事件；真正卡住的是业务 goroutine，它还没被 netpoller 唤醒（比如对端没发数据、超时未设、连接半开）。
实操建议：
- 用
go tool trace查看network poller的唤醒延迟，确认是否真有事件积压 - 检查
net.Conn是否设置了SetReadDeadline，没设会导致 goroutine 永久等待 - 观察
runtime.ReadMemStats中MCacheInuse和MSpanInuse，排除因频繁创建/销毁 fd 导致的内存碎片拖慢 netpoller 初始化
netpoller 是怎么把 fd 和 goroutine 绑定起来的？
netpoller 不直接“绑定”，而是通过 runtime.netpollready 这个回调，在事件就绪时唤醒对应 goroutine。关键结构体是 pollDesc，每个 netFD 持有一个，里面存着 rg（read goroutine）和 wg（write goroutine）两个 guintptr。
使用场景：
- HTTP server 处理长连接时，每个 conn 对应的读 goroutine 就靠
pollDesc.rg记录 - 调用
runtime.pollWait(pd, mode)时，当前 G 会被挂起，并写入pd.rg或pd.wg
容易踩的坑：
- 手动调用
syscall.Epoll_ctl修改 fd 状态，但没同步更新pollDesc，导致事件来了却没人唤醒 - 在
defer里关闭 conn，但之前已触发pollDesc的close逻辑，造成 double-close 或 goroutine 泄漏 - 自定义
net.Listener实现时，没正确初始化pollDesc（比如漏掉runtime.pollDesc.init），导致 accept goroutine 永远不被唤醒
GMP 调度器如何感知 netpoller 的就绪事件？
调度器本身不主动轮询 netpoller，而是依赖 findrunnable 函数里的 netpoll 调用。当 P 的本地队列为空、全局队列也空时，P 会调用 runtime.netpoll（底层是 epoll_wait 或 kqueue），返回一批就绪的 goroutine，直接加入本地队列。
性能影响很实际：
- 如果 P 频繁调用
netpoll（比如每毫秒一次），会增加系统调用开销；但 Go 默认使用timeout=0（非阻塞）或合理 timeout，避免空转 -
GOMAXPROCS设置过大（远超 CPU 核数），会导致多个 P 同时调用netpoll，加剧内核态竞争 - 大量短连接场景下，
netpoll返回的 goroutine 数量少，但调用频率高，此时runtime_pollWait的函数调用开销占比明显上升
实操建议：
- 压测时用
go tool trace -pprof=netpoll抽样分析 netpoll 调用耗时分布 - 避免在 hot path 上反复
conn.SetReadDeadline，它会触发runtime.pollDesc.modify，涉及锁和内存操作 - 若业务允许，用连接池复用
net.Conn，减少pollDesc创建/销毁频次
为什么 sysmon 线程能强制抢占长时间运行的 goroutine？
sysmon 是一个独立的 M，不绑定 P，它周期性扫描所有 G，检测是否超过 10ms 未让出（preemptible 检查）。一旦发现，就向目标 G 所在的 M 发送 asyncPreempt 信号，触发栈分段检查点（stack guard page），迫使 G 在下一次函数调用或循环判断时进入调度器。
关键细节常被忽略：
- 抢占只对“可安全中断”的 G 生效：不能在
runtime系统调用、mallocgc、或持有锁期间触发 - 纯计算型死循环（如
for { i++ }）若不包含函数调用或条件分支，可能逃过抢占——因为没有插入检查点的位置 - Go 1.14+ 引入基于信号的异步抢占，但仍有边界：Linux 下依赖
sigaltstack，某些容器环境（如 gVisor）不支持
线上排查时真正有用的线索：
- 用
go tool pprof -http=:8080 binary binary.prof查看goroutine列表，长时间处于running状态的 G 很可能就是它 - 检查
runtime.ReadMemStats的NumGoroutine是否稳定增长，排除 goroutine 泄漏干扰判断 - 若怀疑抢占失效，加
runtime/debug.SetGCPercent(-1)关闭 GC，再观察是否仍卡死——GC stop-the-world 会强制所有 G 进入调度，是验证抢占是否生效的简易手段
netpoll 和 runtime 调度的交叉点，从来不在理论模型里，而在 strace 输出的每一行系统调用、go tool trace 里那个 200ns 的 netpoll 延迟、以及 pprof 中突然多出来的 5000 个 IO wait goroutine 里。这些才是高级工程师每天要对齐的真实刻度。
