Hyperf进程内存溢出？闭包引用大对象需注意

Hyperf自定义Process进程内存持续单向上涨、数天后触发OOM Kill，根本原因常被误判为PHP内存泄漏，实则多由闭包强引用大对象（尤其是use($this)锁死整个DI容器）、Context未通过defer及时清理、以及PDO连接或文件句柄等C层资源未显式close这三大隐患叠加所致；由于Process常驻不重启且无max_request机制兜底，这些“隐形钉子”会牢牢占据内存，必须改用显式服务获取、生成器流式处理、defer保障上下文清理、严格配对资源释放，并结合strace和swoole_tracker深入追踪C层分配行为，才能真正根治。

Process进程内存持续上涨，重启才回落

Hyperf自定义Process进程内存随运行时间单向爬升，不是瞬时峰值，而是每小时涨几十MB、几天后OOM Kill——这基本可判定为协程或闭包强引用未断，而非临时分配。Process进程生命周期远长于HTTP Worker（常设为常驻），一旦闭包捕获了大对象（如全量用户列表、原始日志数组、未释放的PDO连接），它就会钉在进程内存里不释放。

闭包use($this)直接拖垮整个DI容器

Process类中常见错误是用Coroutine::create()启动协程时写了use ($this)：

public function handle(): void
{
    Coroutine::create(function () use ($this) {
        $users = $this->userService->findAll(); // 全量查出10万行
        foreach ($users as $user) {
            $this->processUser($user); // 每次都带着$this上下文
        }
    });
}

问题在于：$this指向当前Process实例，而Hyperf默认将Process注册进DI容器，$this又隐式持有Container、Config、Db等全部依赖。一个闭包就能把整个容器实例+所有已加载服务+缓存数据全锁死在内存里。

• 改法：所有依赖显式传参，禁用use ($this)
• 改法：若必须访问服务，用Container::get(UserService::class)按需获取，不用$this->链式调用
• 改法：大查询结果不存入闭包，改用生成器逐行处理并unset($row)

Context::set()没配defer，在Process里等于埋雷

Process里调用Context::set('cache', $bigArray)很常见，但Context是协程级存储，而Process进程内可能启动多个协程，且不保证退出顺序。若没配defer，这个$bigArray会一直活在首个协程的上下文中，直到进程重启。

• 错误写法：Context::set('data', $hugeResult);
• 正确写法：defer(fn () => Context::del('data')); 或包裹在try/finally里确保清理
• 更安全做法：Process里避免用Context存大对象，改用局部变量+明确生命周期管理

没close()的PDO连接和文件句柄在Process里永不释放

Process常用于轮询数据库、读取大文件、消费Kafka等场景。若用了PDO但没调$pdo->close()，或fopen()后忘了fclose()，这些C层资源不会被PHP GC回收，memory_get_usage()完全看不到，但ps aux看到的RSS会稳定上涨。

• 检查点：所有new PDO()后是否配对close()；所有fopen()后是否配对fclose()
• 检查点：用gc_collect_cycles() + gc_mem_caches()在循环末尾强制触发GC，观察RSS是否回落
• 检查点：用swoole_tracker开启tracker.enable_malloc_hook=1，确认是否有malloc未匹配free

好了，本文到此结束，带大家了解了《Hyperf进程内存溢出？闭包引用大对象需注意》，希望本文对你有所帮助！关注golang学习网公众号，给大家分享更多文章知识！