各位同学，大家好，坐。
今天我们不聊那些花里胡哨的 ORM，也不讲怎么把代码写得像诗歌一样优美，我们来讲点更“硬核”、更“扎心”的东西——内存。
特别是那种让你半夜两点吓得从床上弹起来，满头大汗，盯着监控大屏上那条逐渐爬升的绿色曲线，然后发现这玩意儿已经突破天际了的情况。
欢迎来到“常驻内存模式下的内存泄漏防御”讲座。
我是你们的讲师，一个在 PHP 内部机制里摸爬滚打多年的“资深老兵”。
第一章：常驻内存的诱惑与恐惧
首先，我们要搞清楚，我们现在处于什么环境？
这可不是你平时写代码用的 php index.php，那种模式下，脚本一结束，内存立马清零，就像去澡堂子洗澡，洗完了脱光光走人，根本不带走一片云彩。
我们现在说的是常驻内存模式（通常由 Swoole、Workerman 或 RoadRunner 提供的支持）。在这种模式下，PHP 进程就像是一个“钉子户”，它启动了，就永远不结束。它得一直挂着，等着你的 HTTP 请求，等着你的 WebSocket 连接，等着你的长轮询。
这就好比你在租了一间一居室的房子里住了十年。前几年没事，但十年后，你会发现家里全是垃圾：过期的快递盒、旧杂志、不用的插座面板，甚至还有以前留下的发霉墙皮。
内存也是一样的。如果你不小心，这些垃圾就会越堆越多，直到有一天，房东（操作系统）告诉你：“哥们，没地儿了，OOM（Out of Memory）了，滚蛋吧。”
这时候，你的报警短信就来了：“服务崩溃，重启中……”
第二章：Fiber——优雅的协程，昂贵的代价
在 PHP 8.1 之前，多任务处理是个噩梦。后来，PHP 引入了 Fiber。这是一个非常棒的特性，它允许你在单线程内实现“协程”式的并发。
简单来说，Fiber 就是一个可以“暂停”和“恢复”的函数。你可以在一个 Fiber 里做复杂的逻辑，比如等待一个网络请求，或者计算一个耗时任务。
$fiber = new Fiber(function () {
// 这里的代码一旦启动，就可以暂停
Fiber::suspend("我暂停了，记得存档");
echo "我恢复了！";
});
$fiber->start();听起来很美对吧？就像你玩单机游戏，存个档，干点别的事，回来接着玩。
但是，Fiber 有一个致命的缺点，或者说，是一个代价高昂的特性——栈。
第三章：Fiber 栈——那个隐形的小房间
注意了，这里有个概念容易混淆：PHP 的堆内存 和 Fiber 的栈内存。
- 普通变量（比如
$user = ['name'=>'Tom']），它们通常分配在堆内存里。PHP 的垃圾回收器（GC）会定期巡逻，发现没人用了，就回收掉。这就像你把书放进仓库，书架满了，仓库管理员会帮你把空箱子打包卖掉。 - Fiber 栈，它是一个独立的内存区域。当 Fiber 被创建时，PHP 会为它分配一段栈空间（默认通常是 64KB，你可以调整）。
一旦 Fiber 被 suspend（挂起），这段栈空间并不会自动释放回操作系统。它就像是你暂停了游戏，存档了，然后你把电脑合上了。那 64KB 的内存虽然现在没在跑你的代码，但它依然占用着物理内存，直到 PHP 进程结束。
这就是问题的核心：如果我们在常驻内存模式下，不断地创建 Fiber，却让它们一直处于挂起状态，不释放，也不销毁，会发生什么？
答案就是：内存堆积。
这种堆积不同于堆内存的泄漏，因为 Fiber 栈是原生内存（通常通过 mmap 或 malloc 分配），GC 看不到它，也管不了它。这就像你在仓库里堆满了纸箱子，仓库管理员（GC）只会清点箱子里的书，但他看不见箱子本身占用的地板空间。
第四章：php-meminfo——侦探的工具箱
既然问题找到了，怎么抓那个偷内存的小偷呢？
你不能光凭感觉。你需要工具。在 PHP 的世界里，我们有 memory_get_usage()，但它只能告诉你“你现在用了多少内存”，它看不到“谁占用了内存”。
这时候，我们要请出今天的重头戏——php-meminfo。
php-meminfo 是一个强大的调试扩展。它不仅能看内存使用量，还能看内存的来源。它能遍历整个 PHP 的 ZVAL（PHP 变量的基本单元）结构，告诉你哪个函数分配了内存，哪个变量占用了空间。
它就像是一个拿着放大镜的侦探，能看清内存分配的每一个细节。
第五章：实战演练——Fiber 的“自杀式袭击”
为了让各位同学印象深刻，我们来写一段“作死”的代码。这段代码的目的就是通过不断地创建 Fiber 栈，来模拟内存泄漏的场景。
<?php
// 1. 引入 Swoole 的常驻内存支持
require_once __DIR__ . '/vendor/autoload.php';
// 2. 开启一个简单的 HTTP Server
$server = new SwooleHTTPServer("0.0.0.0", 9501);
$server->on('request', function ($request, $response) {
echo "接收到请求，开始制造内存泄漏...n";
// 作死的核心逻辑：在循环中不断创建 Fiber
for ($i = 0; $i < 1000; $i++) {
$fiber = new Fiber(function () {
// 在 Fiber 内部搞点事情
$bigArray = [];
for ($j = 0; $j < 100; $j++) {
$bigArray[$j] = str_repeat("data", 1000); // 往栈里塞点数据
}
// 这里不调用 suspend，直接结束，栈会被回收（注意：如果是 suspend 就会泄漏）
Fiber::suspend();
});
// 启动 Fiber
$fiber->start();
}
echo "请求处理完毕，模拟结束。n";
$response->end("OK");
});
$server->start();等等，我刚才代码里有个陷阱！
上面的代码，如果 Fiber 里面没有 Fiber::suspend()，或者 Fiber 执行完就结束了，那么 PHP 是会回收栈的。因为 Fiber 对象本身引用计数归零，就会被销毁，栈也就随之释放了。
真正的“长周期内存泄漏”，通常是这样的模式：
// 修改版：制造真正的泄漏
$fibers = [];
while (true) {
$f = new Fiber(function () {
$data = "Loading...";
// 关键点：挂起，但不释放 Fiber 引用
// 在这里，栈被保留
Fiber::suspend();
});
$fibers[] = $f; // 把 Fiber 引用扔到一个全局数组里
$f->start(); // 启动它
}在这个循环里，我们不断地创建 Fiber，启动它，然后挂起它。我们在 $fibers 数组里保留着这些 Fiber 对象的引用。只要 $fibers 数组不清空，这些 Fiber 就永远无法被销毁，它们持有的栈内存也就永远无法释放。
运行一段时间后，你会发现你的 PHP 进程内存占用飙升，最终 OOM。
第六章：用 php-meminfo 破案
好了，现在让我们来看看，当 php-meminfo 扩展安装好（通常通过 pecl install meminfo 安装）后，如何捕捉这个凶手。
首先，我们需要一个定时器，每隔几秒调用一次 meminfo 的统计函数。这就像是在仓库里每隔一小时拍一次照片，看看是不是又多了几个纸箱子。
use SwooleTimer;
Timer::tick(1000, function () {
// 获取 meminfo 的统计信息
$info = meminfo_dump();
// 我们主要关注两种情况：
// 1. 总内存占用
// 2. ZVAL 的数量（这代表了 PHP 用户的变量数量）
$totalMem = $info['mem']['total_usage'];
$zvalCount = $info['mem']['zval_count'];
echo sprintf("当前内存使用: %.2f MB, ZVAL 数量: %dn", $totalMem / 1024 / 1024, $zvalCount);
// 画个图，或者记录日志
// 这里我们做点更细致的排查，看看是“堆内存”泄露还是“栈内存”泄露
// meminfo 提供了 zval 的详细信息
// 我们可以用 meminfo_get_zval_list() 来遍历
});如果只是用 memory_get_usage()，你可能只能看到内存总量在涨，却不知道涨在哪里。php-meminfo 就厉害了，它能告诉你，那个涨上去的内存里，有多少是“已分配未释放”的，有多少是“幽灵”变量。
让我们看看 php-meminfo 的详细输出。当我们运行上面的“泄漏代码”时，它会打印出类似这样的数据：
[MemInfo] ZVAL Counts:
Integers: 120
Strings: 4500
Arrays: 50
Objects: 2
... (省略其他类型)
[MemInfo] Memory Breakdown:
Memory allocated for user variables: 25.6 MB
Memory allocated for internal structures: 2.1 MB注意看 Arrays 或者 Objects 的数量。
通常，如果我们泄露了堆内存（比如一个全局数组一直往里塞数据），zval_count 会疯狂上涨。
但是，如果是 Fiber 栈内存泄漏，情况会稍微隐蔽一点。因为 Fiber 栈上通常不会存太多复杂的 PHP 对象（除非你在 Fiber 里做了什么奇怪的操作）。Fiber 栈主要存的是原生类型（int, float, char）和少量的引用。
所以，如果你发现 memory_get_usage() 在涨，但是 zval_count 相对稳定，或者只有微小的增长，这就非常可疑了。这意味着 PHP 的垃圾回收器（GC）工作正常，没发现谁持有引用不放，但操作系统层面的内存占用却在增加。
这时候，我们需要深入 php-meminfo 的输出，寻找 “栈内存” 或者 “ZEND_VM” 相关的指标。不同的扩展版本，输出格式可能略有不同，但核心思路是一样的：找出那些生命周期长于请求周期，且未被 GC 回收的内存块。
第七章：防御策略——如何不让 Fiber 变成怪兽
知道了病因，就要治病。作为资深专家，我给出以下几条防御建议：
1. 严格的 Fiber 生命周期管理
这是最重要的。不要把 Fiber 对象保留在全局作用域。
错误做法（就像上面的例子）：
$pool = []; // 错误！全局数组存 Fiber
function task() {
global $pool;
$f = new Fiber(...);
$pool[] = $f;
$f->start();
}正确做法（在 Fiber 内部使用）：
function task() {
$f = new Fiber(function () {
// ... 业务逻辑 ...
Fiber::suspend();
});
$f->start();
// Fiber 对象在这里出作用域，引用计数归零，PHP 引擎会尝试回收
// 如果 Fiber 是 suspend 状态，回收可能会失败（取决于实现），
// 但至少我们不会在全局乱存一大堆。
}2. 谨慎使用 Fiber 的局部大变量
如果在 Fiber 内部定义了巨大的数组（比如 $hugeData = []），请务必小心。因为 Fiber 栈是有限空间的，如果填满了，会导致 Fiber::suspend 失败或崩溃。
$fiber = new Fiber(function () {
// 危险！栈太小了，很容易溢出
$bigStack = str_repeat("X", 1024 * 1024); // 1MB 在栈上
Fiber::suspend();
});解决方案：将大数组移到堆上（PHP 默认行为，只要变量是引用传递或者重新赋值，通常就会移到堆上，但如果直接在 Fiber 函数体内静态定义，可能会留在栈上）。
3. 定期“大扫除”——Garbage Collection
PHP 的 GC 是自动的，但有时它会偷懒。你可以手动触发它：
gc_collect_cycles();虽然这对 Fiber 栈的直接回收帮助不大（因为 Fiber 栈不属于 ZVAL），但清理堆内存能让你的监控数据更清晰。
4. 利用 php-meminfo 进行“压力测试”
在上线前，不要只跑单元测试。写一个脚本，模拟你预期的高并发场景，利用 php-meminfo 监控内存曲线。
// 模拟压力测试脚本
while (true) {
// 模拟 1000 个请求
for($i=0; $i<1000; $i++) {
processRequest();
}
// 打印快照
$info = meminfo_dump();
file_put_contents('mem_log.txt', date('Y-m-d H:i:s') . " | Mem: " . $info['mem']['total_usage'] . "n", FILE_APPEND);
sleep(1);
}如果发现 total_usage 线性增长，那就是有 Bug。
第八章：深入原理——为什么 Fiber 栈这么难搞？
为了让大家彻底理解，我们得从底层的 PHP 内核层面聊一聊。
当你创建一个 Fiber 时，PHP 内核会调用类似 emalloc(size) 的函数来分配一段连续的内存作为栈。这段内存是由 C 语言 管理的，而不是由 ZVAL 引用计数机制 管理的。
这就有个巨大的区别：
- 堆内存：如果没有任何变量指向它，它就是“垃圾”。PHP 的 GC 会定期扫描，发现没人用了，就把内存还给操作系统。这是主动回收。
- Fiber 栈：它是由 Fiber 对象本身持有的。如果 Fiber 对象没死，栈就必须活着。但是，Fiber 是运行在同一个 PHP 进程里的。如果 Fiber 被挂起（suspend），它的执行上下文被保存到了栈里。此时，这个 Fiber 还占着这个栈。
如果你的代码结构是：
$fibers = [];
while(true) {
$f = new Fiber(...);
$fibers[] = $f; // 引用计数 +1
$f->start(); // 运行
// 这里没有 $f = null; 没有从 $fibers 数组里删除
}这就导致了一个死锁：栈里存着挂起的 Fiber，而 Fiber 对象被数组 $fibers 抓着不放。它们两个互相看着对方，谁也不让谁走。于是，内存就这么堆着，直到进程崩溃。
第九章：进阶技巧——监控 Fiber 栈本身
除了用 php-meminfo 看 ZVAL，如果你是在 Swoole 或 Workerman 环境下，还可以利用框架自带的监控。
比如 Swoole 提供了 swoole_get_global_memo 或者类似的内存统计接口。虽然它们可能不会像 php-meminfo 那么细粒度，但它们能告诉你 Fiber 的总数量。
如果 Fiber 的总数量在不断上涨，而你的业务逻辑并没有那么复杂，那么十有八九，是有 Fiber 在被创建后没有正常结束。
代码示例：Swoole 下的 Fiber 监控
// 假设我们有一个 Fiber 管理器
$manager = new FiberManager();
$server->on('request', function ($req, $res) use ($manager) {
$manager->addFiber();
$f = new Fiber(function () use ($manager) {
// 模拟耗时操作
Fiber::suspend();
$manager->removeFiber();
});
$f->start();
});
// 在 Worker 定时器中检查
Timer::tick(5000, function () use ($manager) {
$count = $manager->getFiberCount();
echo "当前活跃 Fiber 数量: $countn";
// 如果数量异常高，直接 kill 掉这个 Worker，防止 OOM
if ($count > 10000) {
echo "警告：Fiber 数量过多，强制重启进程！n";
// 这里通常通过 posix_kill 或者调用框架的重启方法
}
});第十章：总结（伪总结，我们直接进入防御实操）
好了，同学们，今天的讲座接近尾声。我知道你们很想结束，但关于内存泄漏的战斗还没有结束。
记住几个核心要点：
- 常驻内存是双刃剑：它快，但它不释放。你租的是终身房，不是按日租房。
- Fiber 很强大，但栈很娇贵：它像是一个容易过热的 CPU 核，用不好就会积热（内存堆积）。
- php-meminfo 是你的法眼：在堆内存泄漏满天飞的时候，它能帮你揪出那些躲在栈阴影里的元凶。
- 永远不要在全局作用域保留 Fiber 引用：这是铁律。你的 Fiber 需要生命周期的闭环。
最后，给大家留一道作业。
写一个脚本，在一个常驻进程里，模拟 100 个并发请求，每个请求创建 10 个 Fiber，并且让这些 Fiber 挂起 1 秒钟。观察 php-meminfo 的输出，找出那 1000 个 Fiber 占用的总内存大小。
如果你能算出那个数字，并且知道如何优化它，那你今天就出师了。
下课！
（讲师悄悄吐槽：其实刚才那个作业的答案是 6.4MB 左右，因为每个 Fiber 栈 64KB，乘以 1000 就是 64MB，还要减去一些开销。希望你们别被我绕晕了。）
(End of Article)