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常见报错与原因

遇到报错先对号入座：

• 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——这时候多线程反而能并行起来。混淆这两类场景，是绝大多数人踩坑的起点。

Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！