PHP长驻进程内存泄露诊断与优化实战

1. 长驻进程框架的内存管理挑战

在传统PHP-FPM模式下，每个请求结束后会释放所有资源，内存管理相对简单。但Swoole、WebMan、Laravel Octane这类长驻进程框架改变了游戏规则——Worker进程需要持续运行数小时甚至数天，任何微小的内存泄露都会随时间累积，最终导致服务崩溃。

去年我们线上一个基于Swoole的微服务就遭遇过典型的内存泄露：服务在运行72小时后内存从初始的50MB暴涨到2GB，不得不通过定时重启来维持稳定。这种"打补丁"式的解决方案显然不是长久之计。

2. 内存泄露的四大常见根源

2.1 静态变量与全局变量的滥用

php复制class UserService {
    private static $cache = []; // 危险！
    
    public function getUser($id) {
        if (!isset(self::$cache[$id])) {
            self::$cache[$id] = DB::table('users')->find($id);
        }
        return self::$cache[$id];
    }
}

这个看似高效的缓存设计，在长驻进程中会成为内存黑洞。随着请求增多，$cache数组会无限膨胀。正确的做法是使用Redis等外部缓存，或者至少实现LRU淘汰机制。

2.2 未释放的第三方库资源

许多传统PHP库在设计时没有考虑长驻场景。比如：

• 数据库连接池未正确回收
• 文件句柄未关闭
• cURL资源未释放

特别要注意那些在构造函数中初始化资源的库，比如：

php复制$pdf = new PDFlib(); // 内部可能分配大量资源
// 使用后必须显式调用销毁方法
$pdf->delete(); 

2.3 事件监听器的错误注册

php复制$server->on('request', function ($req, $res) {
    Event::listen('user.login', function($user) {
        // 这个监听器会在每次请求时重复注册！
        Logger::log($user->id);
    });
});

每次请求都会新增一个监听器，而旧的监听器不会被自动移除。应该改为在进程启动时一次性注册。

2.4 循环引用导致GC失效

php复制class A {
    public $b;
}
class B {
    public $a;
}

$a = new A;
$b = new B;
$a->b = $b;
$b->a = $a; // 循环引用

即使u