PHP获取当前内存占用，memory_get_usage使用教程

本文深入解析了PHP中`memory_get_usage()`函数的精确含义与常见误区，澄清它返回的是Zend内存管理器当前活跃使用的字节数（非系统RSS或物理内存真实占用），强调加`true`参数才能获取向系统实际申请的内存块大小；同时指出GC延迟、输出操作干扰、Web请求生命周期限制等关键影响因素，并提供主动调用`gc_collect_cycles()`、合理使用`memory_get_peak_usage()`、避免`echo`采样、借助Xdebug等实用技巧，帮助开发者获得稳定可靠的内存监控数据，最终落脚于“判断内存是否合理”需结合扩展、序列化方式和对象图综合分析——真正考验的是对PHP内存模型的理解，而非简单读取一个数字。

memory_get_usage 返回的是什么值

memory_get_usage 返回当前脚本已分配给 PHP 的内存字节数，不是操作系统看到的总 RSS，也不是峰值，只是 Zend 内存管理器当前“认为自己正在用”的量。它默认不包含未释放但已标记为可回收的内存（比如刚 unset 的变量，可能还滞留在内存池里）。

常见误解是以为它能反映真实物理内存占用——其实不能。如果你在 CLI 下跑脚本并用 ps 或 top 看到 15MB，而 memory_get_usage() 只返回 2MB，这完全正常。

• 加 true 参数（即 memory_get_usage(true)）才获取内存管理器向系统实际申请的内存块大小（通常对齐到 256KB 或更大页）
• 不加参数时返回的是“当前活跃使用量”，更贴近你代码中变量实际占的空间
• 这个值在 GC 运行前后可能突变，尤其处理大数组或对象后记得手动调用 gc_collect_cycles() 再测

监控内存增长要避开自动 GC 干扰

PHP 7.3+ 默认启用 Zend GC，但它不会立刻回收循环引用，导致 memory_get_usage() 在短时间内持续上涨，让人误判泄漏。直接在循环里打点测值，很可能看到“阶梯式上升”，其实是 GC 还没触发。

• 在关键节点后主动调用 gc_collect_cycles()，再立刻调用 memory_get_usage()，结果更稳定
• 避免在函数内联、匿名函数闭包密集处高频采样——这些结构容易产生隐式引用，干扰 GC 判定
• CLI 模式下可通过 ini_set('zend_gc_disable', 1) 临时关掉 GC 来做对比测试，但别在线上这么干

如何安全地在 Web 请求中记录内存峰值

Web 场景下，memory_get_peak_usage() 比 memory_get_usage() 更有用，因为它记录从请求开始到当前的最高水位。但要注意：它只在当前请求生命周期内有效，不能跨请求累计。

• 在脚本开头记录初始值：$start = memory_get_usage()；结尾用 memory_get_peak_usage() 获取全程峰值
• 不要依赖 register_shutdown_function() 里的 memory_get_usage() 值——关机函数执行时内存可能已被部分释放，数值偏低
• 如果用了 OPcache，注意 opcache.memory_consumption 是独立于脚本内存的，memory_get_usage() 完全不包含它
• 日志中建议同时记录 memory_get_peak_usage(true)，便于和系统级监控对齐

为什么 echo memory_get_usage() 后数值反而变大

看似奇怪，但很常见：当你用 echo 或 var_dump() 输出 memory_get_usage() 结果时，字符串拼接、格式化、输出缓冲区写入都会额外申请内存。尤其是开启 output_buffering 时，整个响应体先存在内存里。

• 测试时尽量避免在采样点附近做任何输出操作
• 如需记录，改用 error_log($val, 4)（直接写到 SAPI 错误日志）或写入文件，比 echo 更轻量
• 用 Xdebug 的 xdebug_memory_usage() 替代原生函数，它在底层 hook 更干净，受干扰小

今天关于《PHP获取当前内存占用，memory_get_usage使用教程》的内容介绍就到此结束，如果有什么疑问或者建议，可以在golang学习网公众号下多多回复交流；文中若有不正之处，也希望回复留言以告知！