Hyperf内存泄漏排查方法及诊断技巧

Hyperf内存泄漏并非偶然卡顿，而是Worker进程内存呈现规律性持续上涨、重启后回落、随后再度飙升的典型特征；排查时需摒弃盲目翻代码的习惯，优先通过ps aux精准定位高内存Worker，结合dispatch_mode配置、协程上下文清理、静态变量滥用、定时任务与自定义进程资源释放等关键维度层层聚焦，并善用swoole_tracker、Xdebug、Profiler和PHPStan等工具实现从宏观趋势到微观根因的高效穿透，让每一次内存异常都可追踪、可验证、可修复。

Hyperf内存泄漏不是“偶尔卡一下”，而是Worker进程内存持续上涨、重启后回落、过段时间又飙升——这种规律性增长，基本就是泄漏信号。重点不在“有没有”，而在“从哪开始找”。

看准哪个Worker在扛压

别一上来就翻代码。先用ps aux --sort=-%mem | head -10

确认是不是Worker0独占高内存。如果是，优先检查dispatch_mode是否误配为2（所有请求全发Worker0）；如果不是，再按进程ID逐个盯。加日志时带上posix_getpid()，让每条SQL、每个任务都标清归属Worker，避免日志混杂失焦。

盯死协程上下文和静态变量

协程退出不等于内存释放。常见坑点：

• 用Context::set()存了大数组或对象，但没配defer清理，协程结束仍驻留内存
• 类里定义public static $cache = []，每次请求往里塞数据，越积越多
• 自定义进程中用Coroutine::create()启协程，却忘了Coroutine::close()收尾

这类问题用memory_get_usage(true)在关键节点打点，比盲目猜更直接。

定时任务和自定义进程是重灾区

整点报错、内存随时间线性上涨？大概率是定时任务在“静默吃内存”：

• 分钟级任务本地调成秒级复现，单Worker跑15分钟看内存增幅
• 检查crontab-dispatcher进程是否存在资源未释放（如PDO连接未close、文件句柄未fclose）
• 自定义进程若循环拉取数据，确认是否做了分页+unset中间变量，避免全量加载后长期持有

用对工具，别靠感觉

人工review效率低，工具能快速定位根因：

• 启用swoole_tracker（开启tracker.enable_malloc_hook=1和tracker.enable_memcheck=1），它能捕获malloc/free不匹配
• 配合Xdebug生成cachegrind文件，用KCacheGrind看哪段函数堆内存分配最多
• Hyperf内置Profiler组件打开后，可查单次请求的内存峰值和对象实例数

静态分析别跳过：PHPStan能提前揪出未释放资源的调用链，比如某方法返回Resource却没在调用方close。

文中关于Hyperf的知识介绍，希望对你的学习有所帮助！若是受益匪浅，那就动动鼠标收藏这篇《Hyperf内存泄漏排查方法及诊断技巧》文章吧，也可关注golang学习网公众号了解相关技术文章。