Go Runtime（六）：Netpoll与Syscall
本文源码基线为 Go 1.26.2、Linux/amd64。尤其注意：Go 1.26.2 已不再使用历史上的 _Psyscall 状态；旧文章基于 _Psyscall 描述的状态机不能直接套用到当前源码。 在 trace 中，同样一段看起来像“等待 Read 返回”的代码，可能显示为 G 的 Network wait，也可能伴随 OS 线程增加。区别不在 Go 调用语法，而在底层 fd 能否由 runtime poller 以非阻塞方式管理。 网络等待和阻塞系统调用都会让当前 goroutine 暂时无法继续，但 runtime 的处理方式不同： TEXT非阻塞 fd + netpoll G 等在 runtime 中，M/P 可以继续调度 阻塞 syscall M 等在内核中，runtime 设法把 P 交给其他 M 本文沿这两个可观察结果各追踪一次：可轮询网络 I/O 只 park G，真正阻塞的 syscall 则让 M 停在内核，并促使 runtime 把 P 交给其他 M。理解这一区别，就能解释 Go 为什么能用同步风格编写高并发网络服务，以及为什么某些 syscall 仍会增加线程数量。 ...