epoll_wait唤醒频率反映事件循环是否空转或有效做工：轻载时唤醒稀疏但需防ET模式下伪节能，重载时唤醒密集需警惕LT引发的事件抖动；应结合CPU时间片分析能耗配比，并按负载特性选择LT/ET模式及配套读写策略。
直接看 epoll_wait 的唤醒频率，就能判断事件循环在不同负载下是否在“空转耗电”还是“有效做工”。唤醒太密，大概率是 LT 模式下反复通知、或应用层没清空缓冲区；唤醒太稀，又可能漏事件或响应延迟。关键不是次数本身，而是每次唤醒背后有没有真正处理完 I/O。
轻载时：唤醒少 ≠ 节能，要看是否因 ET 配置不当导致饥饿
轻载场景（如长连接低频心跳）下，epoll_wait 唤醒间隔拉长是正常现象。但如果使用 ET 模式却未设非阻塞 socket，或读写未循环至 EAGAIN，内核就认为数据已处理完，后续新数据到来前不会再次通知——表面安静，实则连接卡死或响应延迟。此时 CPU 占用低，但业务 SLA 已受损，属于“伪节能”。
- 检查 socket 是否为非阻塞：
fcntl(fd, F_GETFL) & O_NONBLOCK - ET 模式下每次
EPOLLIN触发后，必须read直到返回-1且errno == EAGAIN - 用
perf record -e syscalls:sys_enter_epoll_wait统计单位时间唤醒次数，再结合cat /proc/[pid]/stack确认线程是否长期阻塞在epoll_wait
重载时：唤醒密 ≠ 高效，警惕 LT 引发的“事件抖动”
重载下（如短连接洪峰、小包密集写入），LT 模式会因接收缓冲区持续有数据而高频触发同一 fd，造成 epoll_wait 返回次数暴增。线程频繁唤醒、上下文切换加剧，CPU 使用率虚高，但实际吞吐未必提升——大量 cycles 耗在调度和系统调用上，而非业务处理。
- 对比 LT/ET 在相同压测流量下的
epoll_wait调用频次（可用bpftrace或syscount-bpfcc抓取） - 观察 CPU 核心泳道中，是否出现大量短小、间隔均匀的时间片（典型空转特征）
- 若发现单次
read只取少量数据（如 1KB），但缓冲区有 8KB，LT 下可能触发 4–8 次唤醒，而 ET 仅 1 次 + 循环读即可覆盖
能耗配比定位：结合唤醒行为与 CPU 时间片分布
单纯统计唤醒次数不够，要叠加 CPU 使用粒度分析。例如：某线程每秒被 epoll_wait 唤醒 5000 次，但每次唤醒后只执行 20μs 业务逻辑，其余时间都在 epoll_wait 阻塞或上下文切换——说明大量能耗花在无效调度上。
- 用性能分析工具框选时间段，查看该线程在各 CPU 核上的运行状态分布（运行/就绪/休眠）
- 开启
View Integrated Scheduling Chain，点击一次唤醒后的运行时间片，追溯其完整调度链：是否刚从epoll_wait返回就立刻进入休眠？还是立即进入业务函数？ - 轻载下理想状态：唤醒间隔长 + 每次处理充分 + 休眠时间占比高；重载下理想状态：唤醒集中但每次处理饱满 + 运行时间片连续、无碎片化
配置建议：按负载特性选择触发模式与读写策略
没有绝对优劣，只有匹配与否。LT 更适合事件稀疏、逻辑简单、难以保证循环读写的场景；ET 更适合高吞吐、可控 I/O 行为的服务，但要求代码严谨。
- 默认优先用 ET：搭配非阻塞 socket + 循环读写 + 边界错误检查（
EAGAIN/EWOULDBLOCK） - 若业务存在不确定长度的协议头解析，或需兼容旧逻辑，可对特定 fd 用 LT，避免复杂状态机
- 避免混用：同一 epoll 实例中不要部分 fd 设
EPOLLET、部分不设，容易引发行为不一致
