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