PHP Fiber 与数据库异步封装的资源释放

把 PDO 查询包进 Fiber，并不等于数据库调用已经异步化。Fiber 只提供可暂停、可恢复的协作式执行上下文；真正的等待仍要由事件循环或异步数据库驱动完成。资源释放的关键是把一次查询任务的连接、语句和事务当成一个整体，在 Fiber 正常结束、抛异常、取消或提前返回时都走同一条收口路径。

先把 Fiber 与数据库异步拆开看

Fiber 的职责是保存调用栈，在 Fiber::suspend() 处把控制权交给调度器，随后用 resume() 或 throw() 继续。它不会把阻塞式 $pdo->query() 变成可抢占的网络等待。如果底层驱动没有异步能力，应该把数据库调用放到合适的 worker，Fiber 只负责等待结果和安排后续处理。

让一次数据库任务拥有自己的资源

不要把可变的 PDO、当前语句和事务标志塞进全局变量。封装函数可以接收一个已经建立的连接，但必须明确谁负责释放；如果连接来自池，则由任务归还而不是随意销毁。下面的示例用一个任务级方法表达这个边界：

beginTransaction();
            $inTransaction = true;
            $stmt = $pdo->prepare('SELECT id, state FROM jobs WHERE id = :id');
            $result = $work($pdo, $stmt);
            // 这里的挂起需要由真正的异步驱动或调度器配合。
            Fiber::suspend($result);
            $pdo->commit();
            $inTransaction = false;
            return $result;
        } catch (Throwable $e) {
            // 让上层看到原始异常，同时保证 finally 仍会执行。
            throw $e;
        } finally {
            // 未提交的事务必须回滚，不能把锁带入连接池。
            if ($inTransaction && $pdo->inTransaction()) {
                $pdo->rollBack();
            }
            // 未消费完的结果集可能占着同一条连接。
            if ($stmt instanceof PDOStatement) {
                $stmt->closeCursor();
                $stmt = null;
            }
        }
    });
}
?>

示例中的 suspend() 只是展示边界：如果它后面永远没有恢复，finally 也不会凭空提前执行。调度器取消任务时，应通过 Fiber::throw() 注入异常，或显式执行同等的取消清理。

结果集、事务和连接分别怎么收口

三类资源不要混成一句“关闭数据库”。

特别是持久连接：脚本结束并不代表底层连接清空，临时表、锁、事务和连接级设置可能被后续请求复用。因此池化封装应提供 reset() 或归还前清理，而不是只依赖 PHP 对象析构。

挂起点放在哪里更安全

不要在持有未消费结果集、打开事务或锁住共享连接时随意挂起。更稳妥的顺序是：执行查询并尽快读取需要的字段，关闭游标；如果确实要等待外部 I/O，先提交或回滚短事务，再挂起；恢复后重新获取任务所需连接。这样 Fiber 被调度器延后时，不会长时间占着数据库资源。

closeCursor();
    }
    if ($inTransaction && $pdo->inTransaction()) {
        $pdo->rollBack();
    }
}
?>

上线前用这份清单复查

• Fiber 被取消时，是否能进入 finally，而不是只处理正常返回？
• 所有只读语句是否在挂起前取完或关闭游标？
• 提交标志是否在提交成功后才改为 false？
• 连接池归还前是否清理事务、锁、临时表和连接级设置？
• 监控是否分别记录活动 Fiber、未完成事务、连接池借出数和归还数？

相关问题

Fiber 能让 PDO 查询真正并发吗？

不能单靠 Fiber 做到。需要非阻塞驱动、事件循环或 worker；Fiber 只负责组织可暂停的调用栈。

只写 $pdo = null 够不够？

不一定。PDOStatement 或其他变量仍引用同一连接时，连接不会关闭；池化连接还应执行状态重置。

为什么 closeCursor() 要放在 finally？

因为异常、提前返回和取消都可能跳过正常的读取末尾；finally 能把未消费结果集的清理集中到一个出口。