答案：Swoole内存泄漏主因是静态变量、闭包引用和资源未释放，需避免全局数据存储、解耦循环引用、协程后清理资源，并设置worker最大请求重启机制，结合监控工具定期分析内存使用。

在使用 Swoole 开发常驻内存的 PHP 服务（如 HTTP 服务器、WebSocket 服务、TCP/UDP 服务）时，内存泄漏是一个常见且严重的问题。由于进程长期运行，局部变量、全局变量、静态变量或闭包引用未及时释放，会导致内存持续增长，最终可能耗尽系统资源。

1. 避免使用静态变量和全局变量存储大量数据

Swoole 是常驻内存模型，static 变量和 global 变量不会在请求结束后自动销毁，它们会一直存在于内存中，直到进程结束。

建议：

• 不要用 static 数组缓存请求数据，比如记录用户请求上下文。
• 避免在类中使用 static $cache = []; 来保存临时数据。
• 如果需要缓存，应设置生命周期和最大容量，并定期清理。

错误示例：

class RequestHandler {
    public static $tempData = [];
    
    public function handle($request) {
        self::$tempData[] = $request->getData(); // 持续累积，永不释放
    }
}

正确做法： 使用协程隔离 + 显式释放，或使用 Table/Swoole\Coroutine\Channel 等机制做有限缓存。

2. 注意闭包中的循环引用

PHP 的垃圾回收机制对循环引用处理有限，尤其在 Swoole 协程环境中更容易出问题。

常见场景：

• 在定时器或异步回调中使用 $this，形成对象自我引用。
• 闭包内持有了外部对象的强引用，导致对象无法被回收。

解决方案：

$timerId = Swoole\Timer::tick(1000, function () use (&$timerId) {
    if (someCondition()) {
        Swoole\Timer::clear($timerId);
        $timerId = null;
    }
});

或者在使用类方法时，避免直接传 $this，改用静态方法或解耦逻辑。

3. 协程上下文管理与 defer 清理

Swoole 使用协程时，每个协程都有独立上下文。如果不注意资源释放，协程退出后仍可能残留引用。

建议：

• 使用 defer 在协程退出前释放资源。
• 显式关闭数据库连接、文件句柄、Redis 连接等。

go(function () {
    $redis = new Swoole\Coroutine\Redis();
    $redis->connect('127.0.0.1', 6379);
    
    defer(function () use ($redis) {
        $redis->close(); // 确保连接关闭
    });

    // 其他逻辑...
});

4. 定期重启 Worker 进程

即使做了内存管理，长时间运行仍可能因第三方库或不可控因素导致缓慢泄漏。

应对策略：

• 设置 max_request 参数，让每个 Worker 处理一定数量请求后自动重启。
• 适用于 HTTP 服务等短生命周期任务。

$http = new Swoole\Http\Server("0.0.0.0", 9501);
$http->set([
    'worker_num' => 4,
    'max_request'  => 1000, // 每个 worker 处理 1000 次请求后重启
]);

这能有效“重置”内存状态，防止长期积累泄漏。

5. 使用工具检测内存使用情况

开发和测试阶段可通过以下方式监控内存：

• 打印 memory_get_usage() 和 memory_peak_usage() 日志。
• 使用 Swoole\Runtime::enableCoroutine() 配合协程调试工具。
• 结合 gdb、valgrind（C 层）或 php 内存分析扩展如 xhprof、tideways 进行深度分析。

echo "Memory: " . memory_get_usage(true) . " bytes\n";

在关键逻辑前后对比内存变化，有助于发现泄漏点。

基本上就这些。Swoole 中防止内存泄漏的核心是：**避免持久化存储无限制数据、及时释放资源、合理利用进程重启机制、主动监控内存状态**。只要保持“常驻内存≠无限增长”的意识，多数问题都能提前规避。