PHP Fiber 在 finally 中恢复执行的资源清理方案

PHP Fiber 在 try 中调用 Fiber::suspend() 时，finally 不会因为“暂停”立刻执行。它要等 Fiber 被继续恢复、向其中注入异常，或 Fiber 对象结束生命周期时，挂起的清理逻辑才会运行。资源清理方案的关键不是在 suspend() 后补一段释放代码，而是让资源的所有权停留在 Fiber 的 try/finally 内，并由调度器明确决定恢复还是取消。

官方地址：https://www.php.net/manual/en/language.fibers.php

只要 Fiber 还处于 suspended 状态，就不要把 finally 当成已经完成；正常路径调用 resume()，取消路径调用 throw()，两条路径都由同一个 finally 关闭资源。

故障现场：暂停不等于清理完成

常见现象是：Fiber 打开了文件、锁或数据库游标，然后在等待调度时暂停。外层看到 start() 返回，就误以为本次任务已经收尾，马上统计资源数或复用句柄，结果发现清理日志没有出现。

这里有两个不同状态：Fiber::suspend() 只是把执行权交还给调用者，Fiber 仍可能继续运行；finally 则属于离开 try 之后的清理阶段。只有 Fiber 从暂停点继续走完、异常穿过 try，或者未完成的 Fiber 被销毁时，清理才有机会发生。

把资源所有权放进 try/finally

资源应当在 Fiber 内部取得，并在同一层的 finally 释放。外层只负责调度，不要同时维护一份“可能需要关闭”的共享标记，否则正常恢复、异常恢复和对象销毁容易重复关闭或漏关。

close();
    }
});

$signal = $fiber->start();
if ($fiber->isSuspended()) {
    // 继续执行后，Fiber 才有机会离开 try 并触发清理。
    $fiber->resume('continue');
}
?>

这个结构的重点是所有权边界，而不是把 close() 放在某个调用者的回调里。若资源是数据库连接、临时锁或文件句柄，也应使用同样的原则：谁创建，谁在 finally 中释放。

正常恢复与异常恢复要分开处理

resume() 会把值作为当前 Fiber::suspend() 的返回值；throw() 则会让异常从暂停点抛出。两者都会让 Fiber 继续穿过 try，但调用者应区分“任务继续”和“任务取消”，否则日志无法解释资源为什么被清理。

close();
    }
});

$fiber->start();
try {
    // 任务正常完成时使用 resume，返回值来自 Fiber 的 return。
    $fiber->resume('continue');
} catch (Throwable $e) {
    // 取消或业务异常在外层记录，不能替代 finally 的资源释放。
    error_log($e->getMessage());
}
?>

如果 resume() 在 Fiber 没有 suspended 时调用，PHP 会抛出 FiberError；因此调度器应先依据状态判断入口，不要用“再试一次 resume”掩盖状态错误。

未恢复 Fiber 的退出策略

有些任务在暂停后永远没有下一次调度。此时要在业务层选择策略：任务必须完成，就保留 Fiber 引用并由调度器继续恢复；任务可以取消，就对 suspended Fiber 调用 throw()，让异常穿过 try/finally；任务彻底丢弃时，释放最后一个引用，让未完成 Fiber 的清理逻辑随生命周期结束执行。

不要把“对象离开作用域”当作主要业务控制流。显式取消更容易记录原因、统计失败任务，也能避免调度器因引用链或容器缓存而延迟销毁。

排查资源未释放的状态表

排查时先记录 Fiber 状态，再记录恢复入口和 finally 日志。这样可以区分“还没恢复”与“恢复后清理异常”，而不是只盯着资源计数。

结论与常见问题

最稳妥的方案是：Fiber 内创建资源，try/finally 内释放；暂停时只上报调度信号；正常任务用 resume()，取消任务用 throw()；对无法继续的 Fiber 采用明确的生命周期策略。这样 finally 的职责单一，调度器也不会错误地把 suspended 当成已清理。

Fiber::suspend() 返回后 finally 会立即执行吗？

不会。它只是暂停 Fiber 并把值交给 start()、resume() 或 throw() 的调用者。

取消 Fiber 时应该调用 resume 还是 throw？

需要表达取消原因时调用 throw()，让异常穿过 Fiber 内部的 try/finally；不要用特殊字符串代替异常语义。

finally 中还能再次暂停吗？

资源清理应保持短小、确定和不可依赖调度，避免在 finally 中引入新的暂停点，尤其不要让清理本身等待同一个调度器。