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

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

时间线：消费结束、迭代器销毁和 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 仍维持在高位，优先考虑分配器复用。若对象计数持续增加，或某个静态缓存、闭包、全局数组仍保存着行数据，才继续沿引用链寻找真正的长期持有者。

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

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

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

exportRows();

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

防复发：用三项检查替代“看起来释放了”

• 在完整消费、提前退出、下游异常三种路径分别确认 finally 日志输出正常。
• 对所有 foreach (... as &$value) 做静态搜索，循环后明确 unset($value)。
• 同时记录对象数量、memory_get_usage(false) 和 worker RSS，避免把分配器缓存当成泄漏。

相关问题

Generator 读完后需要手动调用 close 吗？

不需要依赖通用的 close API，让迭代器自然离开作用域或解除最后一个引用，配合 finally 块就能完成资源释放。

调用 gc_collect_cycles 就一定能降内存吗？

不能。它只处理循环引用场景，不能替代解除普通引用的操作，也不能强迫 PHP 把分配器保留的内存立刻归还操作系统。

为什么 foreach 后数组内容会被改掉？

最常见原因是按引用遍历后的变量仍绑定最后一个元素。循环结束后立即 unset 这个变量，再执行下一轮遍历即可。

小结

Generator 的排查顺序应当是：先确认消费流程是否真的结束，再确认迭代器和循环变量是否仍有其他地方持有引用，最后区分 PHP 分配器缓存与对象长期驻留两种情况。把清理动作放进明确的作用域和 finally，这类内存问题就不会是偶尔复现的疑难杂症，变成可验证、可回归的工程问题。