multiprocessing是绕过gil的唯一标准方案，但需重构内存模型、启动方式、数据传递和错误处理；threading.pool在cpu密集任务中因gil限制无法利用多核，实际仅单核满载。
multiprocessing 是绕过 GIL 的标准方案，但直接替换线程为进程不是“改个 import 就行”的事——它涉及内存模型、启动方式、数据传递和错误捕获的根本变化。
提示词大师-python版
下载
图片提示词生成器？不止如此。 马甲系统 —— 把脑海中的画面，翻译成AI能理解的专业表达。 用得越多，它越懂你：首次需要多问几句确认方向，用久了几乎一说就懂。 用得越多，它越快：缓存机制让后续对话越来越省。 RAG进化：成功案例持续入库，越跑越聪明。 输入「新手指南」查看完整功能介绍
为什么 threading.Pool 在 CPU 密集任务里跑不满多核
ThreadPoolExecutor 启动的线程仍共享同一个 Python 解释器，GIL 会强制它们轮流执行字节码。哪怕你 max_workers=8，实际 CPU 使用率可能长期卡在 100%（单核满载），其余核心闲置。
常见现象包括：
- is_prime、numpy.dot、图像缩放等纯计算任务，多线程耗时 ≈ 单线程 × 1.2～1.5 倍（因线程切换开销）
- top 或活动监视器里只看到一个 Python 进程占高 CPU，其他核几乎空闲
- 日志打印顺序混乱，但结果不一致（比如计数少于预期），这不是 bug，是 GIL 切换导致的竞态本质
ProcessPoolExecutor vs multiprocessing.Pool：选哪个
两者都有效，但行为差异影响调试和迁移成本： -ProcessPoolExecutor 更适合从 ThreadPoolExecutor 平滑切换：接口一致，submit/map 用法相同，异常传播更友好（会 re-raise 到主线程）
- multiprocessing.Pool 更底层，支持 apply_async 的回调、超时控制，也支持 initializer 预加载资源（如初始化大模型、数据库连接池）
- 关键限制：Pool 中的 worker 函数必须是模块顶层函数（不能是类方法、闭包或 lambda），否则在 Windows/macOS 上会报 PicklingError进程间传参和返回值的实际约束
进程不共享内存，所有参数和返回值都会被序列化（pickle），这带来几个硬性限制： - 不能传文件对象、数据库连接、套接字、锁、线程实例等不可 pickle 的对象 - 大数组（如numpy.ndarray）传入时会被完整拷贝，可能触发内存暴涨；建议用 multiprocessing.shared_memory（Python 3.8+）或 numpy.memmap
- 如果函数依赖全局变量（比如配置字典），需显式作为参数传入，或用 initializer + 全局变量在子进程中重建
- 错误堆栈默认只显示“Child process exited with exit code X”，需加 catch_exceptions=True（ProcessPoolExecutor）或捕获 result.get(timeout=...) 才能看到真实异常
Windows/macOS 上必须加 if __name__ == '__main__':
这是 spawn 启动方式的强制要求，漏掉会导致子进程无限递归创建新进程，最终 OOM 或报错：RuntimeError: An attempt has been made to start a new process before the current process has finished its bootstrapping phase.
- Linux 默认用 fork，可以不加，但加上是跨平台安全写法
- 不仅主脚本要加，任何被 import 的模块中定义了 Process 或 Pool 的代码，也得确保调用入口受该条件保护
真正难的不是启动多个进程，而是让它们不互相踩脚、不重复加载、不把内存撑爆、出错了还能定位到哪一行——这些细节不处理，multiprocessing 很快就会比单进程还慢。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
