Swoole中惊群效应真实影响CPU和吞吐，v4.4前默认多进程共享accept导致唤醒竞争；v4.5+默认启用SO_REUSEPORT分流连接，v4.6+自动使用EPOLLEXCLUSIVE避免epoll惊群；协程模式仍需so_reuseport配置才能彻底规避。
惊群效应在 Swoole 中不是理论题，而是真实影响 worker 进程 CPU 使用率和连接吞吐的实操问题。如果你用的是 swoole_http_server 或 Swoole\Server 默认多进程模式（非协程模式），且没显式配置 SO_REUSEPORT 或 epoll 相关隔离机制，那它大概率正在发生。
为什么 Swoole 默认多进程会触发 accept 惊群
早期 Swoole（v4.4 之前）默认让所有 worker 进程调用 accept() 阻塞在同一个监听 socket 上。当新 TCP 连接完成三次握手，内核会唤醒所有等待该 socket 的进程 —— 但只有一个能成功 accept()，其余返回 EAGAIN 或空连接，立刻重试。这导致：
- 大量无意义的系统调用和上下文切换
- worker 进程 CPU 占用不均衡（部分进程频繁被唤醒却无事可做）
- 高并发下
accept()成为瓶颈，strace -e trace=accept可观察到每秒数千次失败调用
SO_REUSEPORT 是目前最直接有效的解法
Linux 3.9+ 支持 SO_REUSEPORT，Swoole 自 v4.5.0 起默认启用（需确认内核版本 ≥3.9）。启用后，每个 worker 进程绑定独立的监听 socket，内核按哈希（源 IP + 源端口）将新连接分发到不同进程，彻底避免共享 wait queue。
验证是否生效：
ss -tlnp | grep :8080
若看到多个 :8080 条目对应不同 PID，说明已启用；若只有一条且 PID 是 master，则未生效。
强制启用方式（Swoole v4.8+）：
Swoole 6.1.1 是一个专为 PHP 设计的高性能事件驱动并发网络引擎。作为稳定版，它修复了编译时对 zlib 依赖的缺失及 curl 模块的内存安全风险。该版本支持协程、多线程与多进程架构，内置 TCP/HTTP/WebSocket 服务器，能够显著提升 PHP 在微服务、实时通信等场景下的执行效率与并发能力。
$server->set([
'open_tcp_nodelay' => true,
'so_reuseport' => true, // 关键配置
]);
注意：so_reuseport 在 Docker 容器中可能被禁用（需检查 /proc/sys/net/ipv4/ip_unprivileged_port_start 和 Capabilities）。
EPOLLEXCLUSIVE 在 epoll_wait 层的补充防护
即使启用了 SO_REUSEPORT，若多个 worker 共享同一个 epoll 实例（比如自定义事件循环未隔离 fd），仍可能在 epoll_wait() 阶段出现惊群 —— 新事件就绪时唤醒全部 waiter。
Linux 4.5+ 提供 EPOLLEXCLUSIVE 标志，Swoole v4.6.0+ 已在内部 epoll_add() 中自动使用该标志（无需手动配置），确保：
- 一个事件就绪时，仅唤醒一个等待该 fd 的 worker
- 避免多个 worker 同时处理同一连接的读/写事件
- 该机制对
SO_REUSEPORT是叠加增强，不是替代
容易被忽略的协程模式差异
很多人误以为“用了 Swoole 协程就天然免疫惊群”，其实不然：
- 协程本身不解决底层 socket 竞争，
Swoole\Coroutine\Http\Server仍依赖底层多进程模型 - 若启动方式为
coroutine => true但未设so_reuseport => true，惊群依然存在 - 真正规避惊群的协程方案是单进程 + 多协程（如
Co\Http\Server配合reactor_num=1），此时无进程竞争，但牺牲了多核扩展性
最稳妥的组合是：多进程 + so_reuseport + 协程，既利用多核，又消除 accept 和 epoll 层的双重惊群。
