当前位置：首页 > 文章列表 > 文章 > php教程 > PHP Generator 关闭后为何还占内存：yield、引用变量与 finally 收尾边界

PHP Generator 关闭后为何还占内存：yield、引用变量与 finally 收尾边界

来源：17golang原创 2026-08-25 16:09:07 0浏览收藏

线上导出任务结束后，PHP-FPM 的 worker 内存没有像预期那样回落，日志里却看不到明显的致命错误。遇到这种现象，先别把锅直接扣给 yield：Generator 只是把遍历过程延后，真正让对象和缓冲区继续存活的，通常是仍被持有的迭代器、foreach 引用变量，或者还没有走完的 finally 清理逻辑。

要点速览

Generator 结束不等于所有外部引用立即消失。
用 memory_get_usage()、引用释放和显式关闭顺序定位问题。
循环变量、异常路径与 finally 都要纳入收尾验收。

先复现：内存不回落到底发生在哪一步

我们先用一个可控的批量读取函数模拟导出任务，不用一上来就跑真实数据库，先把观察点放在“创建、消费、释放”三个时刻就好。

 1, 'payload' => $buffer];
        yield ['id' => 2, 'payload' => $buffer];
    } finally {
        error_log('generator finally');
        unset($buffer);
    }
}

$before = memory_get_usage(true);
$it = rows();
foreach ($it as $row) {
    // 模拟写入文件或发送到下游
}
error_log('after foreach: ' . memory_get_usage(true));
unset($row);
unset($it);
gc_collect_cycles();
error_log('after release: ' . memory_get_usage(true));

这里的关键不是某次数字是否立刻回到起点，而是两次日志之间的趋势，以及 generator finally 是否出现。PHP 的内存分配器可能保留已经申请过的内存供同一进程复用，所以“进程 RSS 没降”不能单独证明泄漏。

PHP Generator 消费完成后仍有引用保留，内存观察点从创建到释放的诊断示意图

时间线：消费结束、迭代器销毁和 finally 不是同一个事件

一次看似简单的 foreach，实际上至少有三层状态：循环是否读完、Generator 对象是否仍被变量持有、Generator 的内部帧是否已经销毁。正常读到末尾时，finally 通常会执行；但只要外部还留着迭代器，相关对象就可能继续可达。

更容易被忽略的是提前退出场景：

$it = rows();
foreach ($it as $row) {
    if ($row['id'] === 1) {
        break;
    }
}
// 此时不要假设 $it 已经不存在
unset($row);
$it->close(); // Generator 没有通用 close() 方法，不能这样处理
unset($it);

Generator 没有可移植的通用 close() 方法。正确的收尾动作是让引用离开作用域或执行 unset($it)，再观察 finally。如果业务需要中途停止，要把释放动作放进明确的 try/finally，而不是依赖某个不存在的 API。

触发条件：foreach 引用会把最后一个元素继续拴住

另一类问题不在 Generator 内部，而是出在消费它的代码里。按引用遍历完成后，循环变量仍然指向数组最后一个元素；如果这个变量后续还被复用，后续的赋值逻辑可能悄悄改写原数组，也会让一部分对象保持可达状态无法被回收。

$items = [
    ['id' => 1, 'payload' => str_repeat('a', 1024 * 1024)],
    ['id' => 2, 'payload' => str_repeat('b', 1024 * 1024)],
];

foreach ($items as &$item) {
    $item['checked'] = true;
}
unset($item); // 解除最后一次引用绑定

foreach ($items as $item) {
    // 这里的 $item 已是普通值变量
}

这条 unset($item) 很小，却是排查“下一次循环数据变了”的第一道检查。它不能解决所有内存问题，但可以切断一个经常被误判为 Generator 泄漏的引用链。

根因定位：把对象可达性和分配器缓存分开看

排查时建议同时记录业务对象数量、引用释放点和 PHP 统计值。memory_get_usage(true) 反映的是 PHP 向系统申请的块，memory_get_usage(false) 更接近当前脚本实际使用量；两者都不应被当成操作系统 RSS 的同义词。

如果 unset($it) 后 finally 日志出现、业务对象计数归零，但 RSS 仍维持在高位，优先考虑分配器复用。若对象计数持续增加，或某个静态缓存、闭包、全局数组仍保存着行数据，才继续沿引用链寻找真正的长期持有者。

PHP Generator 提前退出时通过 unset、finally 与引用解除完成清理的边界示意图

修复动作：给导出任务加上可验收的收尾边界

生产代码可以把迭代器的生命周期限制在最小作用域内，在消费逻辑外层加好兜底处理：

function exportRows(): void {
    try {
        $iterator = rows();
        foreach ($iterator as $record) {
            write_record($record);
        }
    } finally {
        unset($record, $iterator);
        gc_collect_cycles();
    }
}

exportRows();

不要把大数组挂在静态属性上，也不要把整个 Generator 放进长生命周期的容器。对每批数据设置上限，批次结束就释放临时数组；如果下游写入失败，让异常穿过 finally，这样失败路径和成功路径会经过同一套清理动作。