PHP内存溢出问题及优化方法

一分耕耘，一分收获！既然都打开这篇《PHP内存溢出排查与优化技巧》，就坚持看下去，学下去吧！本文主要会给大家讲到等等知识点，如果大家对本文有好的建议或者看到有不足之处，非常欢迎大家积极提出！在后续文章我会继续更新文章相关的内容，希望对大家都有所帮助！

内存溢出需先定位代码而非盲目调高memory_limit，重点排查require、json_decode等操作，用memory_get_usage()和memory_get_peak_usage()插桩分析，注意CLI与Web模式差异及opcache、FPM配置影响。

内存溢出错误直接看 Allowed memory size exhausted

PHP 报这个错时，不是“可能”内存不够，而是 memory_limit 确实被突破了。关键不是盲目调高限制，而是先确认哪段代码在吃内存。错误堆栈里出现的 require、include、json_decode、file_get_contents 或循环中的 array_push 都是高频嫌疑点。

用 memory_get_usage() 和 memory_get_peak_usage() 定位热点

这两个函数不耗资源，适合插桩排查。区别在于：memory_get_usage(true) 返回当前分配的**总内存块大小**（含未释放的碎片），而 memory_get_peak_usage() 返回脚本运行至今的**内存峰值**——后者更反映真实压力。

echo "初始: " . memory_get_usage() . "\n";
$data = file_get_contents('/big-file.json');
echo "读完文件: " . memory_get_usage() . "\n";
$json = json_decode($data, true);
echo "解析后: " . memory_get_usage() . "\n";
echo "峰值: " . memory_get_peak_usage() . "\n";

• 如果 json_decode 后内存暴涨几倍，说明结构嵌套太深或存在循环引用
• 如果 file_get_contents 就占满内存，就得换流式处理（如 fopen + fgets）
• 注意：CLI 模式下默认 memory_limit 常为 -1（不限制），但 Web SAPI（如 Apache/FPM）通常设为 128M 或 256M，行为不一致要留意

ini_set('memory_limit', '512M') 是临时补丁，不是解法

它只对当前请求生效，且不能高于 php.ini 中 memory_limit 的硬上限（除非你有权限改配置）。更危险的是掩盖问题：比如一个本该分页查库的接口，靠提内存硬扛 10 万条记录，下次数据翻倍就又崩。

• Web 场景优先检查 phpinfo() 输出的 memory_limit 实际值，注意 FPM pool 级配置（php_admin_value[memory_limit]）会覆盖全局
• 大数组操作前加 unset($old_array)，别依赖 GC 自动回收——PHP 7.4+ 的 GC 对大数组响应仍滞后
• 对象实例避免在循环中反复 new，改用对象池或复用已有实例

启用 opcache.memory_consumption 反而可能加剧 OOM

OpCache 本身吃内存，尤其当 opcache.max_accelerated_files 设得过大，或大量动态生成文件（如 Twig 编译模板、Laravel 的 storage/framework/views）时，缓存区会快速占满。此时 memory_get_usage() 看不到 opcache 占用，但整体进程 RSS 会飙升。

• 用 opcache_get_status() 查看 memory_usage 和 interned_strings_usage
• 开发环境建议关掉 opcache（opcache.enable=0），避免干扰内存分析
• 生产环境若频繁重编译，说明 opcache.revalidate_freq 太低，导致缓存失效后反复加载，不是内存不够，是配置不合理

以上就是本文的全部内容了，是否有顺利帮助你解决问题？若是能给你带来学习上的帮助，请大家多多支持golang学习网！更多关于文章的相关知识，也可关注golang学习网公众号。