PHP 作为一门托管语言，开发者通常无需手动管理内存，但这并不意味着 PHP 应用不会发生内存泄漏。当常驻进程（如 Swoole、RoadRunner、队列消费者）长时间运行时，内存曲线的持续攀升往往指向内核级或扩展级的泄漏。本文将深入 Zend 内存管理器的底层机制，结合 Valgrind 与 Zend Debug 工具，构建一套可落地的内核级排查方案。
一、理解 Zend 内存管理器与泄漏的本质
PHP 的内存管理分为两层：
- Zend 内存管理器（ZendMM）：为 PHP 变量、数组、对象等提供请求级内存分配，在请求结束时统一释放。若某个变量被长期持有（如全局数组、静态属性），ZendMM 不会主动回收，形成“逻辑泄漏”。
- 系统级分配（malloc）：扩展通过
emalloc以外的malloc/calloc直接向操作系统申请内存。这类分配不受 ZendMM 管辖，若未配对释放，则造成真正的内核级泄漏。
排查的第一步是区分两者：使用 memory_get_usage(true) 观察的是 ZendMM 向系统申请的总量；而 Valgrind 追踪的是进程真实的堆内存。
二、环境准备与编译选项
要获得可分析的符号信息，PHP 必须以调试模式编译：
./configure --enable-debug --disable-all --enable-cli
make -j$(nproc)
关键点：
--enable-debug会启用 Zend 的调试断言，并在内存分配头中记录分配位置。- 禁用优化（
-O0）可避免变量被优化掉导致栈回溯失真。 - 若排查扩展，需以
--enable-<ext>重新编译，并保留.so的调试符号。
Valgrind 需安装 valgrind 及 debuginfo 包。对于 PHP 自身，建议使用 USE_ZEND_ALLOC=0 环境变量禁用 ZendMM，让所有分配直接走系统 malloc，这样 Valgrind 才能完整追踪。
三、使用 Valgrind 定位系统级泄漏
3.1 基础命令
USE_ZEND_ALLOC=0 valgrind \
--tool=memcheck \
--leak-check=full \
--show-leak-kinds=definite,indirect \
--track-origins=yes \
--log-file=valgrind.log \
php script.php
参数说明：
--leak-check=full：输出每个泄漏块的完整栈回溯。--show-leak-kinds=definite：只关注确定泄漏，避免“still reachable”干扰。--track-origins=yes：追踪未初始化值的来源，对定位“条件性泄漏”极有帮助。
3.2 解读输出
Valgrind 报告中的关键字段：
==12345== 1,024 bytes in 1 blocks are definitely lost in loss record 1 of 5
==12345== at 0x4C2FB0F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==12345== by 0x5A3B2C1: my_extension_alloc (myext.c:142)
==12345== by 0x5A3B4D0: zim_myext_process (myext.c:210)
栈顶是分配点，第二行是调用者。若栈中只出现 malloc 而无 PHP 符号，说明该分配发生在扩展内部且未使用 emalloc。
3.3 抑制误报
PHP 启动阶段会分配大量“still reachable”内存（如常量表、函数表），这些并非泄漏。可使用抑制文件：
valgrind --gen-suppressions=all ... 2>&1 | grep -A 20 '{' > php.supp
将生成的抑制规则加入 --suppressions=php.supp，可大幅减少噪音。
四、Zend Debug 与内存追踪
Valgrind 擅长系统级分配，但对 ZendMM 内部的“逻辑泄漏”无能为力。此时需启用 Zend 的内存追踪。
4.1 编译时启用
在 --enable-debug 基础上，确保 ZEND_DEBUG 宏生效。ZendMM 会在每个分配块前附加 zend_mm_block_info，记录大小与分配序号。
4.2 使用 zend_mm_heap 转储
通过 GDB 附加到进程，可直接查看堆状态：
gdb -p $(pidof php)
(gdb) p zend_mm_heap
(gdb) p *zend_mm_heap
若需在代码中主动转储，可调用内部函数：
#include "Zend/zend_alloc.h"
zend_mm_sync();
更实用的方式是利用 zend_mm 的统计接口，在扩展中注册请求关闭钩子：
static void myext_rshutdown(void) {
size_t peak = zend_memory_peak_usage(1);
size_t real = zend_memory_usage(1);
php_printf("peak=%zu real=%zu\n", peak, real);
}
若 real 在多次请求间持续增长，说明存在跨请求的引用残留。
4.3 结合 debug_zval_dump 与引用计数
对于对象泄漏，引用计数是核心线索：
debug_zval_dump($obj);
输出中的 refcount 若大于预期，说明有隐藏引用。常见来源：
- 闭包捕获
$this导致循环引用。 - 静态数组未清理。
- 扩展中
ZVAL_ADDREF后未ZVAL_DELREF。
五、实战案例：扩展中的持久化资源泄漏
假设一个扩展在 MINIT 阶段分配了全局哈希表，并在每个请求中插入数据，但未在 RSHUTDOWN 清理：
ZEND_API PHP_MINIT_FUNCTION(myext) {
ZEND_INIT_MODULE_GLOBALS(myext, NULL, NULL);
return SUCCESS;
}
ZEND_API PHP_RINIT_FUNCTION(myext) {
if (!MYEXT_G(table)) {
ALLOC_HASHTABLE(MYEXT_G(table));
zend_hash_init(MYEXT_G(table), 8, NULL, NULL, 0);
}
return SUCCESS;
}
问题：MYEXT_G(table) 是模块全局，在 RINIT 中若已存在则复用，但从未释放。每次请求插入的数据累积，导致内存线性增长。
排查步骤：
- 用 Valgrind 运行 N 次请求，观察
definitely lost是否随 N 增长。 - 若 Valgrind 未报，说明分配走的是
emalloc，需在RSHUTDOWN中加日志：
ZEND_API PHP_RSHUTDOWN_FUNCTION(myext) {
if (MYEXT_G(table)) {
zend_hash_destroy(MYEXT_G(table));
FREE_HASHTABLE(MYEXT_G(table));
MYEXT_G(table) = NULL;
}
return SUCCESS;
}
- 修复后再次压测，确认
memory_get_usage(true)稳定。
六、最佳实践与工具链整合
- 分层排查：先用
memory_get_usage判断是否 ZendMM 层，再用 Valgrind 确认系统层。 - 持续监控：在 CI 中集成
valgrind --error-exitcode=1，对常驻进程做短时压测。 - 符号保留：生产环境保留
.debug文件，便于事后addr2line还原栈。 - 抑制规则版本化：将
php.supp纳入代码库，随 PHP 版本更新维护。 - 结合
perf与heaptrack：对于性能敏感场景，heaptrack提供更直观的分配火焰图。
结语
PHP 内存泄漏并非无迹可寻。理解 ZendMM 与系统 malloc 的边界，配合 Valgrind 的精确追踪与 Zend Debug 的引用计数分析，可以将模糊的“内存涨了”转化为具体的代码行。内核级排查的核心在于：让每一次分配都有迹可循，让每一次释放都有据可查。掌握这套方法论，常驻进程的内存稳定性将从玄学变为工程。
未经允许不得转载：任鹏个人博客 » PHP 内存泄漏排查实战：基于 Valgrind 与 Zend Debug 的内核级分析
