【经验之谈】Swoole 开发中常见的内存溢出面试题

谈到 Swoole 的内存泄漏问题，有一点必须先说清楚：Swoole 本身并不会像 Ja va 那样抛出一个 OutOfMemoryError 异常。但在常驻进程的模型下，内存泄漏就像是温水煮青蛙——它不会立刻爆炸，而是通过 Worker 进程的内存占用不断攀升，最终触发系统的 OOM Killer 直接把进程干掉，或者让 PHP 报出那句经典的 Fatal error: Allowed memory size exhausted。等到那一天，服务也就挂了。

那么，泄漏的根源通常从哪里来？

静态变量不随请求重置，这才是头号杀手

熟悉 PHP-FPM 的开发者可能会对 static 变量有一种天然的依赖感。在 FPM 模式下，每一次请求都是独立的，PHP 的执行环境随着请求结束被完全销毁，static 变量自然也归零。但 Swoole 不是这样玩的。Worker 进程是长生命周期的，onRequest 回调本质上只是一个普通的函数调用。如果你在函数里写了一句 static $counter = 0;，那么第一次请求执行完毕后，这个变量就被永久固化在进程内存里了。后续的每一次请求，都只是在同一个地址上做累加操作。

常见的翻车现场包括：

• 一个用来统计请求次数的计数器，每次调用 +1，服务不重启就永远不会归零
• 写了一个数组缓存，不停地 push 数据进去，但从来不 unset，内存曲线就像坐了火箭
• 闭包中顺手引用了一个外部的大对象——比如一个 $pdo 实例——结果导致这整块资源都无法被释放

怎么破？

• 把状态逻辑下放到局部作用域里去。该在函数里声明 $data = [] 就老老实实声明，别图省事写成 static $cache = []
• 如果确实有跨请求共享状态的需求，那就正儿八经地用 SwooleTable 或者 Redis 来处理。别指望靠 PHP 的变量生命周期来兜底，它扛不住
• 检查所有使用了 use ($x) 的闭包，确认引用进来的 $x 不是一个长生命周期对象——尤其是那些没有显式关闭的 PDO 连接

max_request 设多少才合理？别乱来

很多新手开发会觉得这个参数“越大越好”，或者反过来认为“设了就万事大吉”。其实都不对。max_request 的本质是一个兜底机制：它让 Worker 在处理完指定数量的请求后，主动优雅退出，然后由 Manager 进程拉起一个新的 Worker。这个重启的过程，帮你在底层把 PHP 层所有残留的引用强制清理干净。

性能和稳定性之间需要找到一个平衡点：

• 设得太低，比如 100，意味着你的代码会比往常频繁地 fork 新进程，CPU 和上下文切换的开销会明显上升
• 设得太高，比如 10000，如果代码里存在泄漏，那么积累的时间会很长，很有可能在 Worker 重启之前，内存就已经把系统拖死了
• 生产环境下，比较稳妥的区间是 500 到 2000。具体值需要根据单次请求的平均内存增量来调整。你可以在 onRequest 的开头和结尾各打一次 memory_get_usage(true)，看看每个请求到底涨了多少内存

另外注意一个细节：max_request 对 TaskWorker 是无效的，如果 TaskWorker 也存在泄漏，需要单独配置 max_task_request。

哪些资源必须手动干预？清单来了

Swoole 不会替你自动回收手动创建的资源句柄，尤其是那些底层的 C 结构体，PHP 的垃圾回收机制覆盖不到它们。下面几类场景，是最容易出问题的地方：

• PDO 和 MySQLi 连接：不要指望 __destruct，那是给面向对象玩的，常驻进程下你需要在 onClose 回调里或者请求结束的时候，显式调用 $pdo->close()
• Swoole HTTP 客户端：即使你设置了 keep_alive => true，使用完毕后也请务必 unset($client)，否则协程栈上的引用会一直残留
• opcache：CLI 模式下，如果开启了 opcache.enable_cli=1，脚本的字节码会被长期驻留。除非有明确需求，否则建议禁用
• 全局 Table 或 Atomic 实例：虽然它们本身是共享内存，但 PHP 层的变量仍然持有句柄。适当的时候 unset($table)，可以减少 PHP 引用计数的压力

onWorkerStop 里销毁对象，真能解决问题吗？

有用，但它的作用范围很有限。所谓有效，是指你在 onWorkerStart 中初始化了明确绑定到该 Worker 生命周期内的对象——比如自建的连接池、全局日志实例、配置缓存等。这些对象，确实应该在 onWorkerStop 中显式地 unset 或调用其 destroy() 方法。你不能指望 PHP 帮你自动析构。

但这里有几个容易踩的坑：

• 如果 Worker 进程被 OOM Killer 异常杀掉，onWorkerStop 不会被触发。所以它不能替代 max_request 的兜底作用
• 不要在 onWorkerStop 中做耗时操作，比如写大文件或者发 HTTP 请求。它会阻塞 Manager 进程，导致新的 Worker 无法被及时拉起

说到底，真正关键的不是“有没有销毁”，而是“每个 Worker 的内存增长是否有一个明确的上限”。想实现这一点，你得同时做到三件事：设置合理的 max_request，显式释放所有关键资源，以及杜绝静态变量污染。三者缺一不可。