PHP 的生成器不是银弹：处理 10G 日志文件时的内存真相

PHP 生成器（Generator）自 PHP 5.5 引入以来，常被宣传为处理大数据集的”内存救星”。yield 关键字确实能够将内存占用从数 GB 压缩到数 MB，这一特性在处理 10G 级别日志文件时看似完美。然而，生成器并非万能银弹，在真实生产环境中，单纯依赖生成器往往无法解决根本问题，甚至可能掩盖更深层的性能陷阱。

生成器的工作机制

生成器通过 yield 实现惰性求值，每次迭代仅保留当前状态，而非一次性将全部数据载入内存。以下是一个典型的日志读取生成器：

function readLogGenerator(string $path): Generator {
    $handle = fopen($path, 'r');
    while (($line = fgets($handle)) !== false) {
        yield trim($line);
    }
    fclose($handle);
}

遍历 10G 日志时，该生成器的内存峰值通常维持在 2MB 至 4MB 之间，相比 file_get_contents 或 file() 的数 GB 内存占用，优势极为明显。但内存低占用不等于执行效率高，这是多数开发者容易混淆的核心误区。

10G 日志场景下的真实瓶颈

当生成器逐行产出数据后，下游处理逻辑往往成为新的瓶颈。假设需要对每行日志进行正则匹配、IP 解析或时间戳转换：

foreach (readLogGenerator('/var/log/access.log') as $line) {
    preg_match('/(\d+\.\d+\.\d+\.\d+)/', $line, $matches);
    $ip = $matches[1] ?? null;
    // 更多业务逻辑...
}

在此场景中，生成器本身不持有大量内存，但 PHP 进程的整体执行时间被严重拉长。10G 文件约含 5000 万至 1 亿行记录，逐行正则匹配在单线程下可能需要数小时甚至更久。更关键的是，若处理逻辑中存在字符串拼接、数组累积或数据库逐条写入，内存泄漏风险将重新浮现。

生成器无法解决的内存陷阱

数组累积是最隐蔽的杀手。即使上游使用生成器，下游代码仍可能在循环内构建统计数组：

$stats = [];
foreach (readLogGenerator($path) as $line) {
    $stats[] = parseLine($line); // 内存再次爆炸
}

一旦 $stats 数组持续增长，内存占用将迅速突破 PHP 的 memory_limit。此外，数据库事务中的逐条插入、未释放的文件句柄、递归调用产生的栈膨胀，均与生成器本身无关，却会在大文件处理中集中爆发。

生产环境的正确打开方式

处理 10G 日志文件时，生成器应作为流水线的一环，而非完整解决方案。推荐采用分块处理策略：将文件按固定行数切分为批次，每批次处理完毕后显式释放资源。结合 SplFileObject 与生成器，可实现更可控的内存管理：

function chunkedLogReader(string $path, int $chunkSize = 1000): Generator {
    $file = new SplFileObject($path);
    $chunk = [];
    while (!$file->eof()) {
        $chunk[] = trim($file->fgets());
        if (count($chunk) >= $chunkSize) {
            yield $chunk;
            $chunk = []; // 显式清空，触发垃圾回收
        }
    }
    if ($chunk) yield $chunk;
}

此模式下，内存占用被限制在单批次数据量级别，同时允许下游进行批量数据库写入或聚合计算，显著减少 I/O 往返次数。对于 CPU 密集型解析任务，多进程扩展（如 Swoole 协程或 ReactPHP） 可将单核串行处理转为并行流水线，进一步压缩总耗时。

总结

PHP 生成器在降低内存峰值方面表现卓越，但低内存不等于高性能，更不等于可扩展。面对 10G 级别日志文件，开发者需清醒认识到：生成器解决的是”读”的问题，而”处理”与”写”的环节仍需严格的资源管控与架构设计。将生成器融入分块策略、配合批量操作与适当的并行化手段，才是生产环境中处理海量数据的稳健之道。