空循环导致cpu高占用，因线程始终处于runnable状态而无主动让出；php-fpm中常见于漏写sleep的轮询逻辑，应通过strace、pidstat、gdb交叉验证并添加合理休眠或改用阻塞调用。
空循环让线程一直处在 Runnable 状态
Linux 调度器只对就绪队列里的线程分配时间片，而 while(true) 这种空循环没有阻塞点（比如 sleep()、read()、epoll_wait()），线程永远不主动让出 CPU，每次被切出去后立刻又回到就绪队列——结果就是调度器反复把它拉起来执行，CPU 时间全被它吃掉。
PHP-FPM 里常见空循环陷阱
这类问题在 PHP 后端服务中并不罕见，尤其出现在自定义长轮询、消息消费、定时任务等场景。典型错误写法包括：
-
while (true) { $data = $queue->pop(); if ($data) { handle($data); } }—— 没有sleep()或usleep()，队列为空时疯狂轮询 -
while (!is_file($lock)) { usleep(1000); }写成while (!is_file($lock)) { }，漏掉休眠 - 用
file_get_contents()或curl_exec()请求外部接口失败后没设超时、也没重试退避，直接重试下一轮
这些都会导致单个 PHP-FPM worker 在用户态空转，%CPU 显示很高，但 top 里状态却可能是 S（Sleep）——那是采样误差，真实行为是“刚唤醒就跑完时间片再排队”，不是真休眠。
怎么确认是空循环而不是其他瓶颈
别急着改代码，先用工具交叉验证：
- 用
strace -p PID -e trace=nanosleep,usleep,sleep,epoll_wait,poll看是否根本没调用任何等待系统调用 - 用
pidstat -u 1观察%usr（用户态 CPU）是否远高于%sys（内核态），空循环基本全是%usr - 用
gdb -p PID -ex "thread apply all bt" -ex quit查看所有线程堆栈，如果大量线程都卡在同一个while循环入口，基本坐实
注意：mmap 无限调用通常指向无限递归，不是空循环；而空循环几乎不会触发 mmap，它只在栈溢出或频繁 malloc 时才出现。
加 sleep 不是万能的，参数得看场景
sleep(1) 对后台常驻进程太粗暴，usleep(10000)（10ms）更常见，但关键要看下游响应节奏：
- 消费 Kafka/Redis 队列：建议
usleep(50000)（50ms）起步，避免压垮 broker - 轮询本地文件或锁：可缩到
usleep(1000)（1ms），但需配合inotify类机制更优 - HTTP 接口健康检查：至少
sleep(3)，否则容易被目标限流或封 IP
更稳妥的做法是用带超时的阻塞调用替代轮询，比如 stream_select()、pcntl_signal_dispatch() 配合信号，或者直接上 Swoole\Coroutine\Channel 这类原生协程通道——空循环本质是“不会等”，而不是“不能等”。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
