各位好，我是你们的内存管理特聘专家。今晚没有PPT，也没有那种能把后排同学催眠的冷气，只有一杯快凉透的咖啡，和一个让我们每个PHP开发者都会做的那同一个噩梦——服务器报警。
想象一下，凌晨三点，你被手机震醒。老板在微信群里发了一串红色的感叹号，伴随着一行文字：“我们的电商大促活动崩了，CPU炸了，物理内存爆了，客户在骂娘，你个TMD是不是又把服务器吃撑了？”
你坐起来，手心冒汗。你说，“老板，这是内存泄漏，是常驻进程在无限吞噬内存。”老板回了一句：“少废话，搞不定明天就不用来了。”
好吧，这就是现实。在这个行业里，如果你不懂内存，你就是个拿着扫把却把房子烧了的园丁。
今天，我们不谈框架，不谈框架，也不谈框架（虽然你们都在用）。我们来聊聊PHP内存泄漏。特别是那种发生在常驻任务（Swoole/Workerman/Supervisor管理的进程）里的“局部变量未释放”导致的物理内存溢出。
准备好了吗？让我们把那个该死的报警器关掉，开始今晚的“内存侦探”行动。
第一章：PHP的内存哲学——它不是C语言，它是个“惜命鬼”
首先，我们要认清PHP的本质。很多从C/C++转过来的老手，总喜欢对PHP指指点点：“你们PHP不用手动释放内存，内存管理烂透了。”
胡说八道。
PHP其实是个非常“惜命”的系统。它的内存管理模型叫Zval结构体。你可以把它想象成一个严格的图书馆管理员。当你声明一个变量 $name = "Tom" 时，PHP会分配一个小盒子，贴上标签，计数器设为1。这就是Zval。
而在常驻进程模式下，PHP的内存管理机制就出现了一个有趣的悖论。在普通脚本中，脚本一跑完，管理员（GC）就把盒子清空了。但在常驻任务中，脚本要跑一个月甚至一年。
这时候，PHP的内存分配器（通常是jemalloc或tcmalloc）会变得非常“吝啬”。它不一定会把内存还给操作系统（free），而是把内存标记为“空闲”，放进自己的“内存池”里，供下一次请求重复使用。
关键点来了： 如果一个局部变量在函数运行完后没有被清理，PHP的内存池就会一直占用这块空间。常驻任务意味着这个“函数”可能永远不会结束。于是，这块内存就在池子里沉睡，永不释放，直到物理内存被填满，触发OOM（Out of Memory） Killer，系统把你的进程干掉。
这就好比你的冰箱，你把过期食物扔进去，但你永远不打开门清理。一年后，你的冰箱满了，食物臭了，你只能扔掉整个冰箱。
第二章：常驻任务中的“幽灵变量”
常驻任务，说白了就是无限循环。一个 while(true) 或者 while($condition)。
在这个循环里，如果我们不小心写了一些东西，就会产生幽灵。
罪魁祸首一：递归中的“递归引用”
递归，是程序员的浪漫，也是内存泄漏的温床。
请看这段代码：
function deepRecursion($n) {
// 创建一个巨大的数组
$data = range(1, 100000);
if ($n > 0) {
// 调用自己
deepRecursion($n - 1);
}
// 这里没有 unset
// 这里的 $data 其实已经没用了
echo "Processing $n...n";
}
// 模拟常驻任务的入口
while (true) {
deepRecursion(100); // 运行一次，内存就涨一点
}为什么会爆？
在 deepRecursion 函数内部，$data 被分配了内存。函数返回时，理论上 $data 应该被销毁。但是，因为 PHP 的作用域机制，如果你在递归调用时，没有显式地清除引用，或者某些不可见的变量捕获了 $data（比如通过闭包或静态变量），内存就会泄漏。
即便在这个简单的例子里，如果 $n 很大，PHP的调用栈会占用大量内存，而每次循环都重新分配这些内存，总量会指数级上升。
罪魁祸首二：大数组的“无限堆积”
有时候，泄漏更隐蔽。
假设我们有一个处理订单的Worker，每次循环处理一条订单：
function processOrder($orderId) {
// 这里的 $tempData 是局部变量
// 但它是一个包含了百万条日志的数组
$tempData = loadHugeLogFromFile();
// 处理逻辑...
$status = saveToDatabase();
// 如果这里忘了 unset($tempData)，或者代码逻辑中出现了意外
// 比如 saveToDatabase 失败了，直接 return 了，但没有清空变量
return $status;
}
while ($orderId = fetchNextOrder()) {
processOrder($orderId);
}诊断视角：
这里最可怕的不是 $tempData，而是引用计数。
当你 return 时，$tempData 的引用计数应该降为0，Zval被销毁，内存归还池。但如果在你的 $tempData 里，存放了对象，而这个对象持有外部资源的引用（比如数据库连接句柄、文件句柄），那麻烦就大了。
更糟糕的是，如果你在循环里不断地往 $tempData 里追加数据，却没有重置数组，哪怕你清空了它：
// 错误示范
foreach ($orders as $order) {
$buffer = []; // 每次循环初始化
foreach ($details as $detail) {
$buffer[] = $detail; // 塞满
}
// 处理 $buffer
if (process($buffer)) {
// 如果这里逻辑混乱，导致 $buffer 没有被正确传递或清理
// 或者你在循环外引用了 $buffer
}
}第三章：实战诊断——如何用“听诊器”听出内存在哪
既然不能直接看物理内存条，我们得用工具。PHP内置的函数虽然简陋，但配合一些技巧，足以让内存无处遁形。
工具一：memory_get_usage() —— 监控心跳
这是最基本的。别总看 memory_get_peak_usage()，那只是告诉你“最疼的时候有多疼”。我们要看的是“增长速度”。
function diagnoseMemory($iterations = 100) {
$memoryStart = memory_get_usage();
echo "开始内存: " . formatBytes($memoryStart) . "n";
for ($i = 0; $i < $iterations; $i++) {
// 模拟某种操作
$fakeData = str_repeat('x', 1024 * 1024); // 1MB
usleep(1000); // 模拟耗时
// 每次循环检查内存
$current = memory_get_usage();
// 只在内存显著增加时打印
if ($current > $memoryStart + (1024 * 1024 * 5)) {
echo "警告：第 {$i} 次循环内存增长了 " . formatBytes($current - $memoryStart) . "n";
// 这里可以插枪，记录当前的调用栈
traceBack();
}
unset($fakeData); // 释放它
}
$final = memory_get_usage();
echo "结束内存: " . formatBytes($final) . "n";
echo "总增长: " . formatBytes($final - $memoryStart) . "n";
}
function formatBytes($bytes) {
// 格式化函数...
return number_format($bytes / 1024 / 1024, 2) . ' MB';
}
function traceBack() {
$trace = debug_backtrace(DEBUG_BACKTRACE_IGNORE_ARGS, 5);
echo "内存泄漏嫌疑点:n";
foreach ($trace as $index => $stack) {
echo "#{$index} {$stack['file']}({$stack['line']}): ";
echo $stack['function'] . "()n";
}
echo "---n";
}技巧： 这里的 DEBUG_BACKTRACE_IGNORE_ARGS 是必须的！因为 debug_backtrace 本身非常消耗内存。如果你在内存已经很高的时候去调用它，它可能会直接把你的进程撑爆。这就是为什么很多Leak发现得很晚——因为在Leak发生时，你根本加不进调试代码。
工具二：Weak Maps（弱引用）—— 高级侦探
如果你使用的是 PHP 7.4+，恭喜你，你有了一把神兵利器：WeakReference。
通常，如果我们在一个循环里创建一个对象并存储在一个全局数组或类属性中，这个对象的引用计数永远不为0，垃圾回收器（GC）不敢动它，内存就一直涨。
弱引用不会增加引用计数。如果对象只有弱引用指向它，且没有强引用，它就会被销毁。
// 模拟一个高性能缓存，但我们不想让缓存占用过多内存
$cache = new WeakMap();
foreach ($bigDataArray as $item) {
// 创建对象
$obj = new stdClass();
$obj->data = $item;
// 存入 WeakMap
$cache[$obj] = ['status' => 'cached'];
// $obj 此时被 cache 引用，还有自己本身的引用（计数为1）
// 但是 WeakMap 里的引用是“弱”的，如果外部没有其他强引用指向 $obj
// GC 就可以随时把它回收
if (memory_get_usage() > 100 * 1024 * 1024) { // 内存警戒线
// 强制触发GC（虽然PHP会自动做，但有时可以手动触发）
gc_collect_cycles();
}
}这在常驻任务中简直是救命稻草。特别是处理大量会话数据时。
第四章：局部变量的“陷阱”——Refcount与IsRef
好，现在我们进入最核心的技术环节。为什么我说“局部变量”是陷阱？因为在PHP中，局部变量不一定真的局部。
场景：全局变量的“幽灵”
这是一个经典的错误：
$globalCache = [];
function doWork() {
// 这里没有 global 关键字，理论上 $localCache 是局部变量
$localCache = [];
for ($i = 0; $i < 10000; $i++) {
$localCache[] = new stdClass();
}
// 等等，如果我们在这里不小心用了 $globalCache...
// 或者我们在某个闭包里引用了它...
return function() use (&$localCache) {
// BINGO! 这里我们把局部变量变成了一级变量（引用传递）
return count($localCache);
};
}解析：
use (&$localCache) 这个 & 符号，是吃内存的恶魔。它打破了作用域的壁垒。$localCache 不再是函数结束就销毁的局部变量，它变成了闭包的捕获变量，进而变成了常驻进程的全局状态。这会导致内存永远增长。
场景：静态变量
静态变量是常驻进程的亲爹。如果你在函数里定义静态变量，并且不断向里面塞东西，内存会爆炸。
function leakingStatic() {
static $bigArray = [];
$bigArray[] = str_repeat('a', 1024 * 1024); // 每次加1MB
return count($bigArray);
}
// 在常驻循环中
while (true) {
leakingStatic();
if (memory_get_usage() > 1024 * 1024 * 1024) { // 1GB
break;
}
}解决方案： 如果你必须用静态变量，必须手动清理。
function safeStatic() {
static $bigArray = [];
// 清理旧数据
if (count($bigArray) > 1000) {
$bigArray = []; // 重建数组，释放旧内存
}
$bigArray[] = 'new item';
}第五章：实战案例——电商系统的“订单大爆炸”
为了把刚才的理论串起来，我们来看一个真实的、高逼格的案例。
问题描述：
我们的一个Swoole定时任务，负责每分钟扫描超时订单。代码写得很漂亮，逻辑很简单。但是跑了一个晚上，物理内存从4G涨到了16G。
排查过程：
-
第一步：加日志。
在循环开始和结束时打印memory_get_usage()。// 看起来代码没问题？ $orders = OrderModel::getTimeoutOrders(100); foreach ($orders as $order) { // 处理逻辑... }结果显示，每次循环结束，内存都降回去了。这很奇怪。
-
第二步：引入 debug_backtrace。
既然代码逻辑看起来正常，那一定是某个看不见的地方在存东西。我们在echo后面加了一个debug_backtrace()。foreach ($orders as $order) { // ... // 临时加一行，看看是哪一行在吃内存 // debug_print_backtrace(); } -
第三步：发现真相。
居然是foreach本身！或者更确切地说，是$orders这个变量。经过深入分析，我们发现
$orders是一个 Result Iterator（迭代器对象）。// 底层代码可能是这样 public static function getTimeoutOrders($limit) { return (new Query())->limit($limit)->get(); }在某些ORM（比如 ThinkPHP 或 Laravel 的旧版本）中，
get()方法返回的不仅仅是数据，它还保留了一个指向查询构建器的引用，或者内部维护了一个指针数组。当
$orders在foreach结束时被销毁，迭代器被释放。理论上没问题。但是！如果这个ORM的查询构建器被定义为静态属性，或者被全局引用了，那么这个迭代器就一直不被销毁。
或者，更糟糕的情况：循环引用。
$orders是一个数组，数组里的每个元素是stdClass对象。如果这些对象里又互相引用（或者引用了外部的$order变量），就会产生循环引用。PHP的垃圾回收机制是引用计数+回收周期。 在单次循环中，循环引用可能无法立即被清理（因为引用计数在减少但没归零）。常驻进程的特性，使得这种“未完全释放”的状态堆积下来，最终触发了GC的“回收周期”，也就是
gc_collect_cycles()。关键时刻：
gc_collect_cycles()是一个极其昂贵的操作。它遍历整个根缓冲区。如果内存泄漏导致了成千上万个循环引用，GC每跑一次就要卡死几秒钟，甚至直接把PHP进程 Crash 掉。
解决方案：
既然是ORM的迭代器问题，我们就必须显式地让它在逻辑之外被释放。
// 错误
foreach ($orders as $order) {
// 处理
}
// 正确
foreach ($orders as $order) {
// 处理
}
unset($orders); // 强制释放迭代器引用或者，如果ORM支持，使用 chunk 方法代替 limit：
// 这样每次只处理100条，PHP会自动帮你析构之前的变量
OrderModel::chunk(100, function($orders) {
foreach ($orders as $order) {
// ...
}
});第六章：常驻任务的内存管理规范
好了，作为专家，我不能只告诉你怎么抓鬼，我还要告诉你怎么建房子（写代码）。
-
警惕“闭包”中的引用传递：
除非你真的需要改变闭包内的局部变量，否则永远不要使用use (&$var)。这是内存泄漏的头号杀手。 -
善用
unset：
在常驻任务中，unset不仅仅是一个习惯，更是一种防御性编程。对于大型数组、大对象、数据库连接，显式释放是必要的。虽然PHP会自动GC，但在高频循环中，显式释放能保证内存分配器的“连续性”，减少内存碎片。 -
避免静态变量滥用：
静态变量是“闭包”的一种。如果你在函数内部定义静态数组并不断追加数据，这就是在自杀。如果必须用，请遵循“先进先出”原则，及时重置静态变量。 -
使用生成器（Generator）：
如果你处理的是海量数据（比如处理日志文件、遍历数据库），千万不要把所有数据读入$array，然后去遍历$array。请使用 生成器。// 坏代码：内存杀手 $allLines = file('huge_log.txt'); // 10GB文件，瞬间吃掉10GB内存 foreach ($allLines as $line) { ... } // 好代码：内存友好 $handle = fopen('huge_log.txt', 'r'); while ($line = fgets($handle)) { // 每次只处理一行，内存占用极低 } fclose($handle); -
定期进行“内存体检”：
在你的常驻任务中，加入一个监控逻辑。比如每运行10分钟，打印一次memory_get_peak_usage()并重置峰值。如果发现内存曲线像火箭一样发射，立刻触发报警或重启进程。
结语：不要做内存的奴隶
各位，PHP 并不差，差的是我们不懂它。在这个云计算时代，内存是昂贵的。虽然我们平时可能感觉不到，但当一个进程把服务器吃干抹净时，我们就是那个罪人。
常驻任务，就像是一场马拉松。你在起跑时消耗了燃料（内存），如果你不懂得在途中补充水分（GC）或者调整配速（代码优化），你一定会倒在终点线前。
记住：局部变量也是变量，它们也会死，但如果你不给它们一把“棺材”（unset），它们就会变成僵尸，永远游荡在你的内存堆里，直到把你的服务器啃光。
好了，今天的讲座就到这里。现在，去检查你的代码，看看有没有哪个 foreach 循环后面忘记写 unset 了吧。别让我在下次见到你时，还得帮你重启服务器。
祝大家都能写出高效、低碳、环保的 PHP 代码。散会！