应避免无间隔轮询，必须加sleep的两类场景是：①阻塞式Socket配合非触发式检测；②轮询式心跳或状态同步；sleep时长需分级设置，控制类50–200ms、实时类1–10ms、心跳类略小于服务端超时阈值的1/3，并用单调时钟补偿防漂移。
在自研网络通信组件中，直接用 while(true) 对 Socket 状态（如 recv() 返回 0 或 -1、select()/poll() 超时后无就绪 fd）做无间隔轮询，会导致线程持续占用一个 CPU 核，利用率接近 100%。这不是高并发的体现，而是低效空转。用 sleep() 是最轻量、最可控的缓解手段，关键在于“怎么睡”和“睡多久”。
明确轮询场景再决定是否 sleep
不是所有轮询都需要 sleep。以下两类必须加 sleep：
- 阻塞式 Socket 配合非触发式检测：例如调用
recv(fd, buf, MSG_DONTWAIT)失败后立刻重试，且未结合epoll_wait()或select()等事件驱动机制 - 轮询式心跳或状态同步：比如客户端每隔 200ms 主动
send()一个 ping 包，但未用定时器调度，而是靠 while 循环 + 当前时间计算延时
若已使用 epoll_wait(timeout_ms) 或 kqueue，且 timeout 设为合理正值（如 10–100ms），则本身已是“等待+唤醒”模型，无需额外 sleep。
sleep 时长要匹配业务节奏，不盲目设固定值
设成统一 1ms 或 10ms 很常见，但容易欠调或过调。建议按实际通信特征分级设置：
- 控制类通道（如配置下发、指令信令）：可设 50–200ms，延迟容忍高，省电优先
- 实时数据通道（如传感器上报、行情推送）：推荐 1–10ms，兼顾响应与负载
- 心跳保活通道：应略小于服务端超时阈值的 1/3（例如服务端踢人是 30s，则心跳 sleep 设为 9–10s）
避免使用 sleep(0) 或 usleep(1) —— 它们无法真正让出调度权，在多数系统上等价于 yield，仍可能造成高频抖动。
用单调时钟 + 差值补偿，防止 sleep 累积漂移
单纯循环 sleep(10) 会因系统调度、处理耗时导致间隔越来越长。更稳的做法是记录下一次执行的绝对时间点：
- 初始化时用
clock_gettime(CLOCK_MONOTONIC, &start) - 每次循环末尾计算：
next = start.tv_sec * 1000 + start.tv_nsec / 1000000 + interval_ms - 当前时间
now若小于next，则usleep((next - now) * 1000)
这样即使某次处理慢了 3ms，下次 sleep 自动补为 7ms，整体周期稳定。
配合非阻塞 I/O 和事件驱动，sleep 只是兜底
sleep 是快速见效的兜底策略，不是架构终点。长期应朝两个方向演进：
- 把轮询逻辑替换为
epoll_wait()或io_uring等内核事件通知机制，让线程在无事时彻底休眠 - 对必须轮询的场景（如某些硬件寄存器 polling），改用
timerfd_create()+epoll组合，由内核定时唤醒，比用户态 sleep 更精准、更低开销
此时 sleep 仅用于初始化阶段、降级模式或调试期快速验证，不参与主路径。
