Python多线程在异步环境中仍必要，根本原因是部分C扩展库（如旧版pandas、OpenCV）调用时释放GIL但不触发事件循环切换，await无效；asyncio仅调度显式支持异步协议的I/O，对传统系统调用“无感”，必须用ThreadPoolExecutor将其封装为可等待任务。
Python多线程在异步环境中依然必要，根本原因很直接：不是所有I/O都能被asyncio接管——尤其是调用底层C扩展库（如numpy.linalg.solve、cv2.imread、sqlite3.connect某些模式）时，它们内部会释放GIL并阻塞线程，但**不触发事件循环切换**，导致await完全无效。
为什么asyncio对某些C库调用“无感”
asyncio只对明确支持异步协议的I/O操作有调度能力，比如aiohttp、aiomysql或asyncio.open。而大量成熟C扩展（特别是未适配PyAsyncMethods的旧库）仍走传统系统调用路径：
- 调用
read()/write()等系统调用时，虽然GIL被释放，但线程进入内核态阻塞，事件循环无法感知该线程“正在等”，也就不会切走 -
time.sleep()这类纯Python阻塞函数更糟——它不释放GIL，直接卡死整个协程上下文 - 像
requests.get()这种纯同步HTTP客户端，底层用socket.recv()阻塞等待，asyncio对其零干预
threading.Thread 是唯一能“逃出”协程阻塞的出口
当必须调用一个无法异步化、又不能改源码的第三方C库时，threading.Thread是标准解法——把阻塞调用扔进独立线程，主线程（或事件循环线程）不受影响：
import asyncio import threading from concurrent.futures import ThreadPoolExecutor <h1>假设这是个无法异步化的C库函数（例如老版本pandas.read_csv）</h1><p>def legacy_c_io_operation(filepath): import pandas as pd return pd.read_csv(filepath) # 内部调用libc，阻塞但释放GIL</p><p>async def run_in_thread(func, *args): loop = asyncio.get_running_loop()</p><h1>使用线程池执行阻塞调用，避免手动管理Thread生命周期</h1><pre class="brush:php;toolbar:false;">return await loop.run_in_executor(None, func, *args)
async def main():
立即学习“Python免费学习笔记（深入）”；
在协程中安全调用阻塞C库
df = await run_in_thread(legacy_c_io_operation, "data.csv") print(df.shape)
-
loop.run_in_executor()底层就是threading.Thread+queue，比手写Thread更安全（自动异常传播、资源回收） - 传
None给ThreadPoolExecutor会复用默认线程池，避免频繁创建销毁开销 - 绝对不要在
async函数里直接调用threading.Thread(...).start()后join()——这会阻塞事件循环
常见踩坑点：GIL释放 ≠ 可被asyncio调度
很多开发者误以为“C库释放了GIL，asyncio就能切走”，这是最大误区。关键区别在于：
- GIL释放：只是允许其他Python线程运行，和事件循环无关
-
事件循环可调度：需要协程显式
await一个Awaitable对象，或底层驱动注册了epoll/kqueue事件 - 典型反例：
subprocess.run()调用外部二进制程序时也释放GIL，但它仍是同步阻塞调用，必须用run_in_executor包装
真正复杂的点在于：有些C库（如新版本psycopg3）提供了原生异步接口，而另一些（如多数OpenCV绑定）至今没有。是否需要线程，取决于你手上那个具体版本的库是否暴露了__aiter__或async def方法——而不是“它是不是C写的”。
