ThinkPHP在Swoole中常驻内存陷阱与内存泄漏的避免方法

提到 ThinkPHP 在 Swoole 常驻内存下“变胖”，说到底就是进程不销毁，导致那些本该在请求结束时归零的对象、静态变量和单例实例，全赖着不走。你扫一眼 memory_get_usage()，它只涨不跌，最终的结果就是 OOM。说实话，这不是什么稀奇事，只是很多人没想到，PHP 传统模型里“用完即焚”的天然优势，在 Swoole 这里反而成了陷阱。

为什么 Swoole 常驻内存会让 ThinkPHP 变“胖”

ThinkPHP 默认的设计，就是每次 HTTP 请求启动、执行、销毁——所有对象、静态变量、单例实例都在请求结束那一刻自动释放。但 Swoole 启动后，进程常驻，App 实例、Container、数据库连接、日志句柄，甚至你写的 static $cache = []，都不会自动清空。久而久之，内存就像堆雪球一样，只增不减，memory_get_usage() 一路飙升，最终 OOM。这不是理论推演，这是线上实实在在的教训。

哪些地方最容易藏泄漏点

不是所有代码都会泄漏，但下面这几类，特别容易“中招”：

• static 属性或全局变量（比如缓存数组、计数器）——下次请求直接复用，越积越多。你以为是缓存，其实是内存冲击波。
• 未显式关闭的 think\db\Connection 或手动 new 的 PDO 实例——Swoole 不会帮你回收连接资源的，你得自己管好。
• 注册了闭包回调但没清理（比如事件监听器、中间件里用 Event::listen() 动态注册）——闭包持有了当前上下文引用，整个请求栈都成了“垃圾”，GC 根本绕不开。
• Log 类被反复调用 Log::init() 却没重置——底层 Handler 实例不断叠加，每个都持有文件句柄或 Socket 连接。你每次请求都“初始化”一次，等于多一层引用。

经验表明，大多数泄漏都是这些“显式但没人注意”的点位累积的。手工排查时，优先盯住它们。

怎么安全地在 Swoole 中用 ThinkPHP

核心原则就一条：主动“归零”，而不是依赖销毁。官方 think-swoole 扩展做了部分隔离，但盲区依然存在：

• 每次请求开始前，调用 App::clear()——清除容器绑定、路由规则、钩子事件。但注意，它不清理 static 属性，这部分得你亲自操刀。
• 数据库连接必须用 Db::connect()->close()或配置 'deploy' => 0 禁用读写分离连接池——否则连接数会直接爆炸。
• 避免在控制器或服务层写 static $data = []——改用 Request::instance()->getCache('key') 或 Redis，用请求级的缓存替换静态缓存。
• 日志务必设为按请求生成独立实例：比如 Log::init(['type' => 'file', 'path' => RUNTIME_PATH . 'log/' . date('Ym/d') . '/'])——否则多个请求共用一个 Handler，文件句柄只会越堆越高。

仔细看，这些操作都不是什么高大上的技巧，就是“用完归零”的朴素原则。但在 Swoole 的常驻内存模型下，你不主动做，系统就不会帮你做。

验证泄漏是否真被堵住

别只看单次请求内存，那说明不了什么。要压测，要看趋势。

• 用 ab -n 1000 -c 10 http://127.0.0.1:9501/ 模拟并发，每 100 次请求后执行 php think swoole:status 查看 worker 内存。
• 在关键位置加 echo memory_get_usage() . PHP_EOL;，对比第 1 次和第 500 次请求的差值——理想情况应该波动不超过 200KB。
• 注意：gc_collect_cycles() 不会立刻生效。Swoole 下建议每 50 次请求后手动触发一次，但别滥用，它本身也有开销。

最后必须警惕的是：最隐蔽的泄漏往往来自第三方扩展或你自己封装的“工具类”。它们悄悄 hold 住了 Request 或 App 实例，只要进程不死，引用链不断，GC 就绕不开。你排查了半天没发现，不是没泄漏，是你没找到。