科技 · 实用指南
Python 报 cannot schedule new futures after shutdown？先证明哪个生命周期先结束
先区分执行器实例已关闭、解释器退出和 asyncio 默认线程池收尾，再决定重试、替换或调整容量。
RuntimeError: cannot schedule new futures after shutdown 不是要求把线程池调大。它说明提交者跨过了生命周期边界：某个 Executor 已关闭、asyncio 默认执行器已收尾，或解释器已经开始退出。精确错误后缀和完整 submit 调用栈会指出该查哪个所有者。
在增加重试前先保留证据。安全修复要让每一代执行器只有一个所有者：先阻止新生产者，再明确等待或取消已接收任务，最后只调用一次 shutdown。若是进程退出，必要控制线程不能只靠 daemon；若由 asyncio.run 管理循环，也应让它管理默认执行器。
1. 先分类精确的关闭信号
保存完整回溯，记录错误是 after shutdown 还是 after interpreter shutdown，以及提交来自 submit、map、调度器、库内传输器还是 run_in_executor。不同路径对应不同生命周期所有者。
在创建、每次接收提交、开始关闭、关闭完成和首次拒绝提交时记录稳定的执行器代号、进程号、线程或任务名与单调时钟。修复必须基于公开所有权和顺序契约。
2. 修复实例关闭后的复用
with 块退出时会关闭执行器。若长期命令对象保存这个实例，第一次运行可成功，第二次就会失败。应当每次独立运行创建新执行器，或把 with 上移到真正拥有整个重复使用周期的组件。
不要在每个调用者里捕获 RuntimeError 后偷偷创建新线程池。所有者应在锁或状态机下发布当前代，进入 draining 后拒绝新任务，并在旧代全部核清后才替换。
3. 修复解释器退出与 daemon 竞态
interpreter shutdown 表明进程生命周期已经结束。常见证据是 main 返回时，daemon 控制器、调度器、回调或传输助手仍准备提交任务；主线程未捕获异常也会形成同类顺序问题。
使用显式停止信号：先停外部生产者，再禁止新提交，等待控制线程，结算已接收 future，关闭执行器，最后让 main 返回。需要可靠完成的工作不能只有 daemon 所有者，atexit 也不能复活已进入解释器收尾的线程池。
4. 尊重 asyncio 默认执行器的所有权
run_in_executor(None, ...) 使用事件循环默认执行器。shutdown_default_executor() 完成后再提交会报 RuntimeError。使用 asyncio.run 时，runner 已负责异步生成器、默认执行器和循环关闭，应用不应重复关闭。
手动管理循环时，先停掉会产生执行器工作的回调和服务，等待相关任务，再 await shutdown_default_executor()，最后关闭循环。其他线程发来的回调必须在边界前被拒绝或排空。
5. 用重启和退出场景证明修复
至少测试四条时间线：连续正常运行两次、仍有排队任务时关闭、生产者活跃时服务重启、主线程异常。每个已接收任务必须只有一个终态，进入 draining 后不得再 submit，线程数要回到基线。
先明确待处理任务应完成还是取消，再针对该策略做断言。真正验收需要时间戳证明生产者停止早于执行器关闭，并在压力测试中没有重复副作用、孤儿线程、吞掉异常或延迟提交。
