为什么Hyperf在执行大数据量导出的过程中内存溢出_使用Generator协程迭代器-php教程-PHP中文网

hyperf导出大数据时rss飙升而memory_get_usage()不涨，因后者仅统计php堆内存，忽略swoole协程栈、c扩展malloc及monolog缓冲区；泄漏主因是协程强引用或c层未释放，generator若配合orm仍全量加载，反加剧泄漏；需直连pdo禁用缓冲、逐行fetch、避免闭包捕获$this、定期gc回收，并考虑进程隔离。

为什么hyperf在执行大数据量导出的过程中内存溢出_使用generator协程迭代器

Hyperf导出大数据时memory_get_usage()不涨但RSS飙升

这是因为memory_get_usage()只统计PHP Zend堆内存，完全看不见Swoole协程栈、PDO/Redis扩展的C层malloc内存、甚至Monolog缓冲区。你看到memory_get_usage(true)是12MB，ps -o rss= -p $(pgrep -f "hyperf")查到的RSS可能已是480MB——泄漏发生在协程上下文强引用或C扩展未释放，不是PHP变量没unset。

Generator本身不解决协程内存泄漏，反而可能加重

在Hyperf里直接用yield返回查询结果，看似流式，实则陷阱重重：

若底层用PDO::fetchAll()或Hyperf\Database\Connection::select()，Generator只是把已加载的全量数组“包装”成迭代器，内存早已吃满
协程未退出前，Generator对象+闭包+上下文里的$this被强持有，GC无法回收
Hyperf默认开启AOP和DI，Cacheable注解生成的闭包会隐式捕获整个容器实例，哪怕Generator执行完，对象仍驻留

真正有效的Generator写法：绕过ORM，直连PDO并禁用缓冲

必须让数据库驱动不缓存结果集，再配合协程安全的逐行消费：

Hyperframes Creative

HyperFrames视频非动画创意指导，包括设计规范（frame.md/design.md）处理、配色、字体设计、旁白及节奏规划等。

下载

使用PDO::MYSQL_ATTR_USE_BUFFERED_QUERY => false（MySQL）或PDO::ATTR_CURSOR => PDO::CURSOR_SCROLL（PostgreSQL）
不用fetchAll()，改用fetch()或fetch(PDO::FETCH_ASSOC)单行读取
Generator函数内避免use ($this)，所有依赖通过参数传入，防止DI容器被钉住
每处理N行（如500行）后显式调用gc_collect_cycles()和gc_mem_caches()

示例关键片段：

public function exportRows(): \Generator
{
    $pdo = $this->pdo; // 避免从容器get，防止$this被闭包捕获
    $stmt = $pdo->prepare('SELECT id,name,amount FROM orders WHERE status = ?');
    $stmt->execute(['paid']);
    while ($row = $stmt->fetch(PDO::FETCH_ASSOC)) {
        yield $row;
        if (++$i % 500 === 0) {
            gc_collect_cycles();
            gc_mem_caches();
        }
    }
}