PHP Swoole/WebMan/Laravel Octane 等长驻进程框架内存泄露诊断与解决方案

PHP Swoole/WebMan/Laravel Octane 等长驻进程框架内存泄露诊断与解决方案

长时间运行的 PHP 应用已经很常见了，上一篇有介绍。Swoole、WebMan、Laravel Octane、RoadRunner、ReactPHP 等框架都可以让单个进程持续在后台运行。直到某一天，突然收到通知，你得服务内存爆了。
这不是“memory_get_usage 值很高，赶紧 unset($array)”这种简单问题。真正麻烦的内存泄漏来自于隐藏的引用持有者——那些你没意识到还在持有的引用——它们阻止了垃圾回收器（GC）释放那些你以为已经是“临时对象”的内存。要捕获这些隐藏的引用，需要两个强有力的工具：弱引用用来监控对象是否按预期被释放，堆快照用来发现谁还在持有这些对象。
下面是一份实战指南，包含了常见陷阱、调试技巧和可复现的解决方案，帮助你解决长驻进程的内存膨胀问题。
为什么会出现内存泄露

PHP 的垃圾回收器（GC）其实很靠谱。PHP 引擎会在对象没有任何引用时自动释放内存，并且能够处理大部分的循环引用。真正导致内存被“钉住”的原因通常不是 GC 的问题，而是你忘记了还存在的那些引用：

• 一个闭包捕获了 $this，而 $this 又持有服务容器，容器又包含了整个应用的依赖。
  
• 事件监听器被注册到调度器中后，从来没有被移除。
  
• ORM 的身份映射（如 Doctrine 的 UnitOfWork）在作业间没有被清空。
  
• 以字符串为 key 的静态缓存，从来不做清理。
  
• 延迟或重试队列中的闭包引用了大量上下文数据。
  
• foreach (&$x) 循环后忘记调用 unset($x)，导致最后一个元素的引用仍然存在。
  
• ReactPHP/Swoole/Webman 中的定时器在作业结束后很久还持有回调。
  
• 日志处理器的缓冲机制（如 "fingers crossed" 类型）在默默地累积记录。
  

当你阅读代码时，这些都不像“泄露”。每个看起来都很合理。但是问题就隐藏在它们创建的隐形持有者中。
内存泄露快速检测方法

监控进程的常驻内存大小（RSS）随时间的变化，而不仅仅是看 memory_get_usage(true) 的值。你需要关注的是在不同作业之间内存是否有持续上升的趋势。
在每个作业完成后手动触发垃圾回收（gc_collect_cycles(); gc_mem_caches();），然后观察 RSS 是否有明显下降。如果 GC 后内存仍然没有释放，说明某个地方还在持有强引用。
设置内存或作业数的软限制，在达到阈值时主动重启进程（例如处理了 N 个作业或运行了 M 秒）。这不是治本的方案，但可以作为调试期间的保护措施。
做好了这些预防措施，现在来看看如何定位和解决实际的泄漏问题。
使用 WeakMap 监测对象生命周期

弱引用可以让你监控对象的生命周期，而不会影响其生命周期。在 PHP 8+ 中，WeakMap 非常适合用来监控“这些对象应该在作业完成后被释放”。
轻量级泄露监控工具

[code]