PHP Fiber 中断后资源怎么收尾：finally、取消信号与协程状态验收

线上批量读取文件时，Fiber 里最容易漏掉的不是暂停逻辑，而是暂停之后谁负责关闭文件句柄。Fiber 被抛出异常、被外层取消，或者主循环提前结束时，只有把资源放进 finally，再配合明确的取消状态，清理动作才不会依赖调用者“记得收尾”。

Fiber 的暂停与资源生命周期是两件事：恢复、抛错、取消都要经过同一条 finally 清理路径，最后再用状态和资源计数验收。

故障现场：任务结束了，句柄还在增长

假设一个导入任务每次从 /var/tmp/import-queue 取一个文件，读取到一半时把控制权交回调度器。正常完成时问题不明显，真正暴露缺陷的是超时：外层把取消标记设为 true，Fiber 下次恢复后直接返回，已经打开的句柄却没有关闭。

这个症状通常表现为“Fiber 数量已经归零，但进程的打开文件数仍在上升”。先别急着给调度器加重启，应该把一次任务的时间线记录出来：打开文件、暂停、恢复、读取、取消、关闭。

按时间线拆开：暂停不是退出，取消也不是回收

Fiber::suspend() 只是把执行权交还给调用方。Fiber 仍然拥有自己的栈和局部变量，文件对象不会因为暂停自动关闭。调用 throw() 或让 Fiber 内部抛出异常时，PHP 会沿着异常路径寻找 finally；如果代码把关闭动作写在正常返回之后，那条语句可能永远走不到。

另外，外层不能用“resume() 没有返回结果”判断任务是否结束。恢复后可能再次暂停，也可能抛出异常。应该在每次交互之后检查 Fiber 是否已终止，并把取消原因留在任务记录中。

触发条件：哪几种中断最容易绕过清理

恢复时才发现取消

调度器在 Fiber 暂停期间收到取消请求，设置标记后恢复 Fiber。Fiber 如果只在读取成功后关闭句柄，而没有在取消分支退出前进入 finally，就会留下资源。

外层提前停止轮询

更隐蔽的情况是外层直接停止调用 resume()，把 Fiber 对象丢弃。不要把垃圾回收当成业务清理策略；明确调用一个让 Fiber 走完清理路径的取消协议更容易验收。

修复方案：让每个资源都有唯一的收尾位置

下面的示例把句柄放在 Fiber 内部打开，并用 finally 保证关闭。取消只负责改变状态和抛出业务异常，资源回收仍由同一处完成：

 'opened']);
            if ($cancelled()) {
                throw new ImportCancelled('cancel requested');
            }

            return (string) fread($handle, 4096);
        } finally {
            if (is_resource($handle)) {
                fclose($handle);
            }
        }
    });
}

这里有两个细节值得保留。第一，fopen() 失败时不会把无效值交给 fclose()。第二，取消检查放在恢复后的安全边界上，异常抛出后仍会穿过 finally。如果资源不止一个，建议在同一个 try 中按打开顺序登记，按关闭顺序释放。

验收方法：同时核对状态、结果和资源数

测试不能只覆盖成功读取。至少准备成功、取消和读取异常三条路径。每条路径都记录 Fiber 的终态、异常类型，以及打开句柄计数是否回到基线。

$fiber = readChunk($path, fn () => $cancel);
$fiber->start();
$first = $fiber->getReturn(); // 只有终止后才读取

if (!$fiber->isTerminated()) {
    $cancel = true;
    $fiber->resume();
}

if (!$fiber->isTerminated()) {
    throw new LogicException('fiber did not terminate');
}

示例中的 getReturn() 只能在 Fiber 已终止后读取，实际项目应把恢复和异常捕获包在调度器的统一入口里。不要在 Fiber 还可能暂停时读取返回值，也不要吞掉取消异常后继续复用同一个任务对象。

防复发：把取消协议写进接口和监控

接口层明确区分“暂停等待输入”和“取消后清理完成”。监控层至少保留任务 ID、最后阶段、取消原因、终止时间和资源基线。若取消任务在一个短窗口内没有进入终态，就报警；若句柄基线持续偏离，再去排查异常路径是否漏了 finally。

对长任务而言，资源计数比 Fiber 数量更有价值。Fiber 可以正常减少，而句柄、临时文件或数据库游标仍然泄漏。把这两类指标放在同一张验收表里，故障定位会快很多。

相关问题

Fiber 暂停后能不能直接销毁对象？

不建议把对象销毁当作业务取消协议。应先让任务收到取消信号并走完清理，再释放调度器持有的引用。

finally 里关闭已经关闭的资源会报错吗？

关闭前先判断资源是否仍有效，或者让资源包装对象提供幂等的 close 方法。清理代码本身也要能安全重复进入。

什么时候需要事件循环？

Fiber 只提供暂停和恢复机制，不负责 IO 事件通知。需要同时管理大量网络 IO 时，应让事件循环决定何时恢复 Fiber，并继续沿用同一套取消与 finally 约定。

小结

Fiber 的难点不在于把代码暂停，而在于把暂停、恢复、异常和取消统一到可验证的生命周期里。资源在 Fiber 内打开，就由 Fiber 内的 finally 收尾；调度器只传递取消信号并核对终态。这样即使任务在半路退出，也能用状态和资源指标证明它确实收干净了。