默认使用 asyncio 内部维护的全局 threadpoolexecutor 实例，懒初始化，最大线程数为 min(32, os.cpu_count() + 4)，所有未显式传入 executor 的 run_in_executor 调用均共享该池。
run_in_executor 默认用的是哪个线程池
Python 的 asyncio.loop.run_in_executor 不创建新线程池，而是复用 concurrent.futures.ThreadPoolExecutor 的默认实例——也就是 asyncio 内部维护的全局线程池，最大线程数通常为 min(32, os.cpu_count() + 4)（CPython 3.8+）。
这个池子在事件循环首次调用 run_in_executor 时懒初始化，之后所有未显式传入 executor 参数的调用都共享它。
- 你不能靠多次调用
run_in_executor自动获得“隔离”的线程资源 - 如果某次提交的任务长期阻塞（比如没设 timeout 的
requests.get），会吃掉池中线程，拖慢后续所有异步任务的执行响应 -
asyncio.get_event_loop().set_default_executor(...)可以替换它，但极少有人这么做，且只影响当前 loop
为什么不能假设每次 run_in_executor 都开新线程
线程池复用是设计使然，不是 bug。它的目标是避免频繁创建/销毁线程的开销，但代价是资源竞争和任务间隐式耦合。
典型误判场景：以为「A 任务耗时 10s」和「B 任务耗时 100ms」互不影响——实际上如果池只有 4 个线程，而 A 占了 3 个，B 就得排队等。
立即学习“Python免费学习笔记（深入）”；
- 池大小不随负载动态伸缩，固定上限
- 没有任务优先级、超时控制或取消支持（
Future.cancel()在运行中任务上基本无效） - 异常不会自动传播到调用方，除非你 await 返回的
Future
什么时候该自己传 executor 而不是依赖默认池
当你需要控制并发粒度、隔离关键路径、或规避默认池的不可控行为时，必须显式构造 ThreadPoolExecutor 并传给 run_in_executor。
常见适用点：
- IO 密集型短任务（如小文件读写）→ 用小池（
max_workers=4）防抢占 - CPU 密集型任务（如
math.factorial(10**5)）→ 必须用ProcessPoolExecutor，否则白搭 async - 有明确 timeout 或 cancel 需求 → 自建池 + 包装成可中断的
Future（需额外逻辑） - 多个服务模块共用一个 event loop → 各自用独立 executor，避免互相卡死
示例：
from concurrent.futures import ThreadPoolExecutor<br>executor = ThreadPoolExecutor(max_workers=2)<br>await loop.run_in_executor(executor, some_blocking_func)
默认池的生命周期和关闭风险
默认线程池由 asyncio 管理，事件循环关闭时会尝试 shutdown(wait=True)，但实际行为取决于 Python 版本和 loop 实现（尤其是 uvloop）。它不会主动清理正在运行的线程，也不会等所有任务完成才退出。
后果很直接：
- 程序退出时若还有任务在默认池中运行，可能被强制终止，引发
RuntimeError或静默丢任务 - 测试中反复创建/关闭 loop 容易触发
BrokenThreadPool或ShutdownError - Web 框架（如 FastAPI）里依赖默认池做 blocking IO，重启时若没等池清空，下次启动可能拿到已 shutdown 的 executor
真正安全的做法：自己管理 executor 生命周期，用 atexit 或框架钩子显式 shutdown()，而不是指望默认池“自己会处理好”。
