pool.flushAll() 不生效是因为它仅清空空闲连接队列，不关闭已借出连接或底层TCP连接；正确做法是先确保所有连接调用 release()，必要时手动 close() 未归还连接，并配合 dispose_callback 和 OnShutdownInterface 安全清理。
为什么 pool.flushAll() 在 Hyperf 中不生效
直接调用 pool.flushAll() 通常不会关闭任何连接，因为 Hyperf 的协程池（如 Hyperf\Pool\SimplePool 或基于 Swoole\Coroutine\Channel 的实现）默认不支持「主动驱逐并关闭所有连接」的语义。该方法只是清空内部的可用连接队列（$this->queue），但已借出的连接仍被使用者持有，底层 TCP 连接也不会被 close()；更关键的是，多数 Pool 实现里 flushAll() 并不遍历并销毁已创建的连接资源。
正确释放连接：必须归还 + 显式关闭未归还连接
协程池连接的生命周期由借用方控制：你得先确保所有已 get() 的连接都调用了 release()，否则它们会一直占用、超时前也不会被回收。而真正要“全部关闭”，需分两步：
- 对每个已借出但尚未归还的连接，手动调用其
close()或等效销毁方法（如PDO::close()、Redis::close()、Co\Http\Client::close()） - 再调用
pool->flushAll()清空空闲队列，避免后续误复用残留句柄
例如针对 Redis 连接池：
// 假设 $pool 是 Hyperf\Redis\Pool\RedisPool 实例
$connection = $pool->get();
// ... 使用后必须 release
$pool->release($connection); // ✅ 必须做
// 若连接意外泄露（比如异常未 catch 导致没 release），可尝试强制 close：
if ($connection instanceof \Redis) {
$connection->close(); // 注意：部分版本可能抛异常，需 try-catch
}
如何安全地在服务关闭时清理整个池
Hyperf 提供了 Hyperf\Contract\OnShutdownInterface，适合在 Worker 退出前统一收尾。但注意：OnShutdown 不保证所有协程已结束，所以不能依赖「当前协程内遍历池中连接」——因为池本身无公开 API 暴露所有已创建实例。
推荐做法是：在初始化池时，自己维护一个弱引用容器，并在 createConnection 回调中注册连接对象：
// 初始化池时
$connections = new \WeakMap();
$pool = new SimplePool([
'max_connections' => 20,
'create_callback' => function () use ($connections) {
$conn = new \Redis();
$conn->connect('127.0.0.1', 6379);
$connections[$conn] = true; // 自动弱引用，不阻止 GC
return $conn;
},
'dispose_callback' => function ($conn) use ($connections) {
unset($connections[$conn]); // 归还时清理记录
$conn->close();
},
]);
// OnShutdown 中遍历并关闭所有存活连接
\Swoole\Coroutine\run(function () use ($connections) {
foreach ($connections as $conn => $_) {
if ($conn instanceof \Redis && $conn->isConnected()) {
$conn->close();
}
}
});
常见陷阱与兼容性提醒
不同组件的 Pool 行为差异很大，别假设统一：
-
Hyperf\Database\Pool\Pool（PDO）：连接对象没有close()方法，靠 GC 或脚本结束自动释放；flushAll()只清队列，不 kill 连接 -
Hyperf\Redis\Pool\RedisPool：底层\Redis实例有close()，但调用后若再调用get()会重建，所以 flush + close 是安全的 -
Swoole\Coroutine\MySQL类型池：连接是协程上下文绑定的，不能跨协程 close，也不应手动 close —— 应严格release()后交由池管理 - 自定义池若未实现
dispose_callback，flushAll()后连接对象还在内存里，TCP 连接可能持续到超时
最稳妥的方式永远是：业务层确保每次 get() 都配对 release()；全局清理只作为兜底，且必须结合具体客户端类型判断是否支持显式 close。
