如何通过使用Python的multiprocessing模块优化多线程数据处理的性能问题？

本文共计985个文字，预计阅读时间需要4分钟。

多线程不提速，不是代码写错了，是GIL+锁死+CPU+密集型任务。 你使用 threading 或 concurrent.futures.ThreadPoolExecutor 处理图像压缩、文本解析、数值计算这类任务时，耗时反而比单线程长，根本原因就在这里——Python的全局解释器锁（GIL）强制所有线程轮流执行，无法实现真正的并行。解决方法非常直接：

为什么 multiprocessing.Process 比 threading.Thread 快？

每个 multiprocessing.Process 运行在独立的 Python 解释器进程中，拥有自己的内存空间和 GIL，因此能绕过 GIL 限制，在多核 CPU 上真正并行执行。

• 适用于 CPU 密集型任务：如图像解码、特征编码、矩阵运算、正则匹配等
• 不适用于频繁跨进程传递大对象的场景（序列化开销高）
• 启动开销比线程大，适合单次任务耗时 ≥ 100ms 的场景
• Windows 下必须将进程创建逻辑放在 if __name__ == '__main__': 块内，否则会递归启动新进程

用 Pool.map 替代 ThreadPoolExecutor.map

这是最常用也最稳妥的替换方式，接口几乎一致，但底层走的是进程池而非线程池。

• 原多线程写法：ThreadPoolExecutor(max_workers=4).map(func, data_list)
• 改多进程写法：from multiprocessing import Pool; with Pool(4) as p: p.map(func, data_list)
• 注意：func 必须是可序列化的顶层函数（不能是 lambda、嵌套函数或类方法）
• 如果 func 需要多个参数，用 functools.partial 或封装成接受元组的函数

共享状态与通信的常见陷阱

进程间默认不共享内存，global 变量、类属性、模块级缓存在子进程中都是副本，修改不会回传。

立即学习“Python免费学习笔记（深入）”；

• 不要依赖全局变量缓存配置或中间结果——每次进程启动都会重新加载模块
• 需共享只读数据（如大字典、模型权重）时，用 multiprocessing.Manager().dict() 或 multiprocessing.Array，但有性能损耗
• 更高效的做法是：把只读数据作为参数传入函数，或在子进程内按需加载（例如每个进程自己 torch.load 模型）
• 避免在 map 中做文件写入竞争——不同进程同时写同一文件会出错，应让每个进程写独立路径

实际加速效果取决于任务粒度与 I/O 比例

不是开了 8 个进程就一定快 8 倍。真实瓶颈可能藏在别处：

• 如果单个 process_image 耗时仅 5ms，进程启动/通信开销可能占主导，此时建议批量处理（如每进程处理 100 张图）
• 若任务含大量磁盘读取（如遍历 10 万张小图），I/O 本身成瓶颈，加进程数反而引发磁盘争抢，此时应配合异步读取（aiofiles）或预加载到内存
• CPU 核心数 ≠ 最优进程数；通常设为 os.cpu_count() - 1 更稳，留一个核给系统调度

最容易被忽略的一点：你写的“预处理函数”是否真的在做 CPU 工作？比如用 PIL.Image.open 读图后立刻 .convert('L')，这部分是纯 CPU 计算；但如果只是 open + save，那本质是 I/O，此时多进程收益有限，甚至不如多线程+预读缓冲。