协程数量不由扩缩容控制,而是通过channel等机制实现并发节流;swoole协程轻量且自动回收,所谓“动态扩缩容”实为调度控制;需手动构建协程池限制并发数,worker进程才需真正扩缩容。

协程数量不是靠“扩缩容”控制的
协程本身没有“扩容”或“缩容”的概念——它不像进程或线程那样需要预分配资源池。Swoole 协程是轻量级执行单元,启动成本极低(KB 级栈),go() 调用即创建,执行完自动回收。所谓“动态扩缩容”,实际是指对协程并发行为的节流与调度控制,防止无限制 go() 导致内存暴涨或调度延迟。
用 Channel + pool 模拟可控并发池
真实业务中常需限制同时运行的协程数(比如并发调用第三方 API、批量写 DB),这时应手动构造协程池,而非依赖“自动扩缩”。Swoole 本身不提供内置协程池,但可用 Swoole\Coroutine\Channel 实现信号量式控制:
// 示例:最多同时运行 5 个 HTTP 请求
$channel = new Swoole\Coroutine\Channel(5);
for ($i = 0; $i push(true); // 阻塞直到有空位
// 执行实际任务
$client = new Swoole\Coroutine\Http\Client('httpbin.org', 443, true);
$client->get("/delay/" . rand(1, 3));
echo "Task {$i} done\n";
$client->close();
$channel->pop(); // 释放一个槽位
});
}
-
Channel容量即最大并发数,超出会阻塞push(),天然限流 - 不用手动维护协程生命周期,
pop()后其他协程可立即进入 - 避免因瞬间启动数万协程导致栈内存碎片化或 GC 延迟
注意 Swoole\Runtime::enableCoroutine() 的副作用
启用协程运行时后,所有 I/O 操作(如 file_get_contents、PDO 查询、cURL)都会自动协程化,但部分扩展未适配,可能引发死锁或内存泄漏:
Swoole 6.1.1 是一个专为 PHP 设计的高性能事件驱动并发网络引擎。作为稳定版,它修复了编译时对 zlib 依赖的缺失及 curl 模块的内存安全风险。该版本支持协程、多线程与多进程架构,内置 TCP/HTTP/WebSocket 服务器,能够显著提升 PHP 在微服务、实时通信等场景下的执行效率与并发能力。
- 未加
defer的资源(如$client->close())在协程退出时未必释放 - 某些 C 扩展(如旧版 Redis 扩展)在协程模式下不安全,必须换用
Swoole\Coroutine\Redis -
sleep()、usleep()在协程模式下会自动转为非阻塞,但time_nanosleep()仍会阻塞整个进程
真正需要“扩缩”的是 Worker 进程,不是协程
如果你观察到 CPU 或内存持续升高,问题大概率不在协程数量,而在:
- Worker 进程数配置不合理:
worker_num过小导致请求排队,过大则上下文切换开销上升 - 协程内持有长生命周期对象(如大数组、静态缓存、未关闭的句柄),GC 无法及时回收
- 定时器未清理:
Swoole\Coroutine\Timer::tick()创建后忘记clear(),持续占用内存
协程的“动态性”体现在调度层,而不是数量管理——它该起多少,由业务逻辑决定;你真正要调的,是 Worker 数、超时阈值、连接池大小这些硬边界参数。










