go程序中永远不该手动调用epoll_wait，因为runtime.netpoll已封装并接管全部就绪等待逻辑；手动调用会破坏调度一致性，引发挂起、惊群或ebadf错误。
Go 程序里根本不会调用 epoll_wait，你写的任何 net.Conn.Read、http.Serve 或自定义 accept 循环都不涉及手动 epoll_wait 调用。 运行时已用 runtime.netpoll 封装并接管了全部就绪等待逻辑，手动介入只会破坏调度一致性，引发挂起、惊群或 EBADF。
为什么你永远不该在 Go 里调用 epoll_wait
Go 的网络模型不是“用 epoll 实现的 I/O 库”，而是把 epoll 作为底层事件源，与 goroutine 生命周期强绑定的调度机制。一旦你绕过 net 包直接调 epoll_wait：
- 必须配对使用
runtime.Entersyscall/runtime.Exitsyscall，否则 M 线程卡死，P 无法调度其他 G - 多个 goroutine 同时对同一 epoll fd 调
epoll_wait，触发内核惊群：所有 M 被唤醒又休眠，CPU 拉满，accept延迟飙升 -
epoll_wait返回后，你得自己查 fd、自己调read/write、自己处理EAGAIN和超时——这等于重写internal/poll模块，且无法复用pollDesc中的定时器和 goroutine 队列 - 若该 fd 已被 runtime 注册（比如来自
net.Listen），重复监听会导致epoll_ctl(EPOLL_CTL_ADD)失败返回EBADF，后续Read()永久挂起
runtime.netpoll 是怎么替代 epoll_wait 的
runtime.netpoll 不是封装，而是重定义了“等待”的语义：它不返回就绪 fd 列表，而是直接唤醒对应 goroutine。关键路径如下：
- 每个
net.Conn对应一个netFD，其内嵌pollDesc，里面存着rg/wg—— 即等待读/写的 goroutine 指针 - 当
conn.Read()发现缓冲区空，当前 goroutine 立即gopark，同时pollDesc.rg被设为该 G 地址 -
runtime.netpoll在后台线程中持续调用epoll_wait（仅一个或少数几个实例），拿到就绪 fd 后，直接查该 fd 关联的pollDesc，取出rg或wg，调goready - 被唤醒的 goroutine 不再需要轮询，直接继续执行
read系统调用——此时内核缓冲区必有数据（或 EOF）
这个过程完全绕开了用户态事件循环，也无需你维护 fd 集合、超时堆或就绪队列。
Linux 性能分析与调优专家，覆盖 CPU、内存、磁盘 I/O、网络、内核参数、编译优化、容器/K8s。适用场景：系统卡顿/高负载、内存不足/OOM/Swap 高、CPU 异常/iowait 高。
真要观察 epoll_wait 行为，得看内核视角
想确认某个 Go 进程是否正确使用 epoll，不要翻 Go 源码或打日志，直接查 /proc：
- 查 epoll 实例：
ls -l /proc/<pid>/fd/ | grep epoll</pid>，看到类似epoll:[12345]表示 runtime 已创建 - 查注册的 fd 数量：
cat /proc/<pid>/fdinfo/<epoll_fd></epoll_fd></pid>（需 kernel ≥ 4.18），其中events:行列出所有被监听的 fd 及事件类型 - 对比
netstat -an | grep :port | wc -l和 fdinfo 中的 fd 数量，若后者远大于前者，说明有泄漏或未关闭的连接
注意：runtime.netpoll 内部的 epoll_wait 调用不可被 ptrace 或 strace 完整捕获——因为它是运行时私有系统调用，且常与 netpollBreak 管道协同中断，避免长阻塞。
真正容易被忽略的点是：你以为在“优化 epoll”，其实只是在干扰 pollDesc 的状态机。比如没调 conn.SetReadDeadline()，pollDesc.rt 就不会设定时器；比如在 handler 里做耗时计算，M 被占住，runtime.netpoll 就没法及时轮询——这些才是实际影响就绪响应延迟的根因。
