Python多线程无法加速CPU密集型任务，因CPython的GIL限制同一时刻仅一个线程执行字节码；判断GIL瓶颈可观察psutil.cpu_percent(percpu=True)是否单核满载；ThreadPoolExecutor增线程数反致变慢即为GIL锁死信号；ProcessPoolExecutor是稳妥替代方案，需注意函数定义位置、参数可序列化、共享内存优化及if name == "__main__":保护。
Python多线程在CPU密集型任务中根本无法利用多核，这不是代码写得不好，而是CPython解释器的GIL（GlobalInterpreterLock）强制限制：同一时刻，只有一个线程能执行Python字节码。哪怕你开了20个线程、跑在32核服务器上，真正在跑Python计算的，永远只有1个核。
怎么快速判断你的任务是不是被GIL卡死了
别猜，看实际行为：
- 用
psutil.cpu_percent(percpu=True)观察——如果返回数组里只有1个值长期接近100%，其余全在5%以下，基本就是GIL锁死的信号 - 把
ThreadPoolExecutor的max_workers从4调到16，耗时不降反升，甚至变慢，说明线程切换开销已压过收益 - 你以为是IO密集型？但请求回来立刻做大量
json.loads()、pandas.DataFrame.apply()或正则匹配，这些纯Python计算部分一上来，GIL就又锁住了
ProcessPoolExecutor 是当前最稳妥的替换方案
它和ThreadPoolExecutor接口几乎一致，但底层走的是multiprocessing，每个子进程有独立的GIL，天然支持多核并行：
python-script-generator
下载
快速生成专业的 Python 脚本和应用代码。一键创建完整项目结构，支持CLI、API、爬虫、Bot、Django等多种项目类型，包含完整的项目结构、配置文件、依赖管理、测试、README和文档。
- 函数必须定义在模块顶层，不能是嵌套函数或
lambda，否则会报PicklingError - 参数必须能被
pickle序列化——避免传self、闭包、不可序列化的对象（如数据库连接、文件句柄） - 大数组别直接传参，改用
multiprocessing.shared_memory或先存磁盘，子进程只传路径 -
Windows和macOS下必须加if __name__ == "__main__":保护，否则子进程重复导入主模块，导致无限fork、爆内存
别踩这些坑：multiprocessing常见报错与原因
遇到报错先对号入座：
立即学习“Python免费学习笔记（深入）”；
-
AttributeError: Can't pickle local object→ 函数定义在另一个函数内部，或用了lambda；移到模块顶层重写 -
BrokenPipeError或EOFError→ 子进程提前退出，常因未加if __name__ == "__main__":，尤其在Windows/macOS上 - 结果为空或部分丢失 → 用了
executor.map()但没消费迭代器，比如忘了加list()或循环遍历，它其实是惰性求值 - CPU跑不满但耗时没降 → 任务本身I/O占比高，或进程启动/数据序列化开销远超计算时间，这时反而该回退用
ThreadPoolExecutor
真正绕开GIL不是靠调参或换库，而是明确区分任务类型：纯Python计算就交出去给进程，带大量C扩展（如NumPy数组运算）的代码，其实早就在底层释放了GIL——这时候多线程反而能并行起来。混淆这两类场景，是绝大多数人踩坑的起点。
