Swoole协程处理CPU密集型任务性能分析

首先需要明确一个核心观点：使用Swoole协程处理CPU密集型任务，不仅无法获得性能提升，反而可能导致整个服务瘫痪。这与许多人理解的“并发能力”概念存在本质区别。

协程与CPU密集型计算之间，天然存在不可调和的矛盾。

为什么协程在CPU密集场景下会失效

协程的核心机制基于协作式调度，即协程主动让出CPU资源。然而，纯计算型操作——例如大规模循环、矩阵运算、正则表达式回溯——完全不涉及任何IO事件，像co::sleep()、co::read()这类挂起点根本不会被执行，调度器无法获得介入机会。最终结果是一个协程彻底独占整个Worker进程的CPU时间片，其他协程只能等待。

几个直观的典型表现：

• 即便设置 worker_num=8，在 top 中可以看到 8 个 PHP 进程，但其中 1 个 CPU 占用率达到 100%，其余 7 个几乎空转
• 根本原因在于 PHP 是单线程解释器，所有协程都在同一个 OS 线程中运行，无法利用多核并行计算能力
• 常见误区是认为使用 go(function () { heavy_calc(); }) 就能实现“并发执行”，实际上协程只是排队等待同一个 CPU 资源，没有任何并发收益

task_worker_num 是唯一可靠的解决方案

真正能够隔离CPU密集型任务的方案，唯有 task_worker_num。它启动的是独立子进程（而非线程），每个 task worker 拥有完整的 PHP 解释器和独立的内存空间，天然绕开了单线程瓶颈。

几个必须注意的关键细节：

• 必须在 swoole_server->set() 中显式设置 task_worker_num >= 1，设为 0 或不设置则相当于未启用
• 投递任务必须使用 $server->task($data)，如果在 onReceive 中直接调用函数，则等于白费配置
• 在 onTask 回调中可以放心使用 usleep()、json_decode()、shell_exec()，这些操作不会阻塞主 Worker
• 但需注意，task 进程之间不共享 global、static 变量，每次调用都会创建全新的实例

declare(tick=N) 抢占式调度仅理论可行，生产环境慎用

PHP 的 declare(ticks=N) 在理论上可以实现协程级抢占，但代价高昂且不实用。每执行 N 条低级语句就会触发一次 handler，计算速度被严重拖慢，并且 tick 无法覆盖所有语句（如类定义、方法声明），边界情况极难控制。

• 压测数据足以说明问题：1000 万次 $i++ 在 ticks=100 设置下，耗时增加约 40%，CPU 效率大幅下降
• 在 handler 中增加时间判断并调用 co::yield()，会引入额外上下文切换开销，反而放大延迟
• Swoole 官方从未推荐过此方案，企业级服务中它基本只出现在概念验证演示中

OpenCPU 或远程计算才是高负载场景的真正出路

当计算任务复杂度超出单机能力——例如模型推理、批量图像处理——单纯依靠 task worker 已不现实。此时应将计算逻辑外移，通过 HTTP 或 Socket 异步委托给专用计算节点。

• Swoole 端只需使用 SwooleCoroutineHttpClient 发起请求，全程协程安全
• OpenCPU 方案提供沙箱隔离、资源限制、自动扩缩容，比自建 task worker 更稳定且省心
• 关键点在于必须设定超时（timeout）、重试（retry）和降级逻辑，防止计算服务不可用时拖垮网关

最后提及一个容易被忽略的点：许多看似“CPU密集”的问题，实际上属于伪命题。例如未加索引的 MySQL 全表扫描、未设置超时的 cURL、同步写入机械硬盘的日志——这些才是真正的性能杀手。先确认瓶颈所在，再决定采用 task 还是调整架构，切勿一上来就堆叠子进程。