Go的net/http默认不会惊群，因其runtime用单线程轮询epoll fd并统一管理accept队列；自建epoll服务若多goroutine并发调用EpollWait同一fd则触发惊群。
为什么 Go 的 net/http 默认不会惊群，但自建 epoll 服务会
Go runtime 的 netpoll 本身基于 epoll（Linux）或 kqueue（macOS），但它在调度层做了关键隔离：每个 net.Listener 只绑定到一个 OS 线程（M），accept 队列由 runtime 统一管理，不会让多个 goroutine 同时调用 accept()。惊群效应只出现在你绕过 net/http、直接用 syscall.EpollWait + 多个 goroutine 轮询同一个 epoll fd 的场景。
常见错误现象：accept() returns -1, errno=EGAIN 或大量 goroutine 在 epoll_wait 上空转，CPU 拉满但连接建立缓慢。
- 真正触发惊群的是「多个 goroutine 对同一 epoll fd 调用
epoll_wait」，不是并发 accept - Go 的
runtime.netpoll内部只用一个线程轮询 epoll fd，其他 goroutine 通过 channel 等待就绪事件，天然规避了惊群 - 如果你用
golang.org/x/sys/unix手动封装 epoll，并启动 4 个 goroutine 同时EpollWait同一个 fd，就踩坑了
如何安全地在 Go 中复用 epoll fd（避免惊群）
核心原则：一个 epoll fd 必须且只能由一个 goroutine 调用 EpollWait；新连接/事件分发走 channel 或 work-stealing 队列，不重复轮询。
典型错误写法：for range []int{0,1,2,3} { go func() { for { unix.EpollWait(...) } }() } —— 这是惊群温床。
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 正确做法：单 goroutine 负责
unix.EpollWait，收到EPOLLIN后，把conn fd发给一个chan int，由 worker goroutine 池调用unix.Accept - 注意
unix.Accept返回的 fd 需立刻设置为非阻塞（unix.SetNonblock(fd, true)），否则可能卡住 worker - 如果用
net.Conn封装，记得用net.FileConn+fd构造，别再走net.Listen套路，否则又回到 runtime 默认模型
Go 1.21+ 的 net.ListenConfig 和 SetDeadline 对高并发的影响
这不是 epoll 优化，但常被误当作“底层优化”来用——实际它影响的是连接建立后的读写行为，和惊群无关，但配置不当会放大性能问题。
常见错误现象：短连接服务 CPU 不高，但 P99 延迟飙升，strace 显示大量 recvfrom 阻塞在 EAGAIN 上。
-
net.ListenConfig.Control可以设置 socket 选项（如SO_REUSEPORT），但它只对 listener fd 生效，**不能解决惊群**；SO_REUSEPORT是内核分流，让多个 listener fd 共享同一个端口，每个 fd 自己 epoll，本质是“多进程/多 goroutine 各管各的 epoll”，不是共享一个 epoll fd -
SetDeadline在高并发下有显著开销：每次调用都会触发 timer 插入/删除，建议用固定超时 +context.WithTimeout替代频繁调用 - 如果真要极致压测，禁用
KeepAlive（SetKeepAlive(false)）可减少定时器数量，但需业务层保证连接健康
调试惊群问题的三个真实命令
别猜，用系统工具看真相。以下命令在生产环境轻量可用，不需要重启服务。
-
strace -p $(pgrep yourapp) -e trace=epoll_wait,epoll_ctl,accept -f 2>&1 | grep -E "(epoll|accept)"：确认是否多个线程在同时epoll_wait同一个 fd -
ss -tuln | grep :yourport：检查是否启用了SO_REUSEPORT（输出里带skmem或多次出现同一端口，说明多个 listener fd） -
cat /proc/$(pgrep yourapp)/stack | grep -c "epoll_wait"：统计当前所有线程中处于epoll_wait状态的数量，>1 就危险
最易被忽略的点：你以为自己在优化 epoll，其实 runtime 已经帮你做了；真要动手，先确认你是否真的在用裸 epoll —— 90% 的“Go 惊群”问题，其实是误用了第三方网络库或自己写的 syscall 封装，而不是 Go 本身的问题。
