Hyperf协程调度对CPU密集型任务无效，因其仅在I/O操作时触发yield，而纯计算不触发系统调用，导致协程霸占线程、单核100%但QPS卡死；应剥离计算至TaskWorker、增加Worker进程数或分片并行处理。

Hyperf 协程调度本身不直接提升 CPU 利用率。

它解决的是 I/O 等待导致的 CPU 空转。若业务逻辑是纯 CPU 密集型任务，如大量数学计算、图像处理、加密解密，协程挂起并无意义，CPU 反而可能因调度开销略降效率。

为什么 Hyperf 的协程调度对 CPU 密集型任务“无效”

协程调度并不是随时都会发生。它只会在碰到 swoole_hook_flags 已经覆盖的 I/O 操作时才真正生效，比如 mysql_query、curl_exec、file_get_contents 这类调用。

反过来看，像纯 PHP 循环、hash_hmac、imagecreatefromjpeg 这类不会触发系统调用的操作，Swoole 是感知不到的，自然也不会主动 yield。

结果就是，这个协程会一直占着当前线程不放，其他协程也就拿不到执行机会。

此时的典型表现是：单核 CPU 持续 100%，但并发请求数没涨，QPS 卡死，协程数暴涨却无实际吞吐提升。这不是调度器坏了，而是它根本没被触发。

• 协程不是多线程，不自动并行 CPU 计算
• swoole_cpu_affinity 设置仅绑定 Worker 进程到 CPU 核，不影响协程内计算是否并行
• PHP 是单线程解释器，一个协程内的密集计算会阻塞整个 Worker 进程

如何识别当前瓶颈是 CPU 密集而非 I/O

可以先用 top -Hp {pid} 查看 Worker 进程内各线程的 CPU 占用。

若某个线程长期 95%+，且 swoole_server->stats() 中 coroutine_num 高但 request_count 增长缓慢，基本可判定为 CPU 瓶颈。

更准的方法是启用 opcache.file_cache 并开启 xhprof 或 blackfire。

重点看耗时函数是否集中在 for、array_map、json_encode 等非 I/O 函数上。

• 不要依赖 ps aux | grep php 的 %CPU —— 它显示的是进程级，掩盖了协程级阻塞
• strace -p {pid} -e trace=epoll_wait,read,write 若几乎不输出，说明几乎没有 I/O 等待
• Hyperf 日志中频繁出现 Coroutine::sleep 但无效果？那大概率是 sleep 被忽略（未 hook）或计算压垮了调度器

真正能提升 CPU 利用率的实操手段

必须跳出“靠协程调度榨干单核”的误区。

Hyperf 场景下有效路径只有三条：

• 把 CPU 密集任务剥离到独立 Process 或 TaskWorker：用 $server->task() 提交，避免阻塞协程调度器；返回结果用 onTask 回调处理
• 启用多 Worker 进程：通过 worker_num 配置（如设为 CPU 核数），让不同 Worker 并行跑不同请求；注意 max_coroutine 应略高于平均并发，避免协程创建失败
• 对可并行计算做分片 + Parallel：比如批量处理 1000 条数据，拆成 10 组每组 100 条，用 HyperfUtilsParallel 启动 10 个协程——但前提是这些计算不共享状态，且每组耗时不悬殊

示例关键代码

$parallel = new Parallel(4); // 最多同时跑 4 个子任务
foreach (array_chunk($data, 100) as $chunk) {
$parallel->add(function () use ($chunk) {
return array_map(fn($x) => hash_hmac('sha256', $x, 'key'), $chunk);
});
}
$results = $parallel->wait(); // 阻塞等待全部完成，但期间其他协程仍可运行

最容易被忽略的调度器隐性损耗

协程调度器本身有开销：每次 yield/resume 约 50–100ns。看似 negligible，但当单请求内发起上千次微小 I/O，如循环查 Redis 单 key，调度频次爆炸，反而会拖慢整体吞吐。

这时候，优先考虑把操作合并起来往往更划算。

• 比如用 $redis->mget(['k1','k2','k3']) 一次性取回数据，替代连续三次 $redis->get()
• 写库时尽量通过 HyperfDbConnection::transaction() 做批量提交
• 不要在协程里高频调用 Co::sleep(0) 来“让出控制权”，这通常没有实际意义，反而会带来额外的调度抖动

真正的高 CPU 利用率，来自合理分配：Worker 进程吃满物理核，协程专注等 I/O，计算任务下沉到进程/外部服务。

混淆 Reactor、Worker、协程调度三者的职责，是绝大多数性能调优失败的起点。

《夸克》非常好用的免费AI浏览器

下载APP查看