python multiprocessing

### 1. 他是什么Python的multiprocessing模块说白了就是用来绕过GIL全局解释器锁的那把钥匙。CPython的GIL一次只允许一个线程执行字节码所以多线程在CPU密集型任务上基本是摆设。而multiprocessing通过创建独立的进程——每个进程都有自己的Python解释器和内存空间——直接绕开了这个限制。你可以把它想象成开了一家火锅店一个线程就像只有一个厨师在厨房里忙活哪怕你雇了十个服务员灶台只有一口锅效率依然上不去。而multiprocessing相当于让每个厨师都有自己的灶台和锅食材数据虽然不能随便共享但烹饪速度确实能翻倍。2. 他能做什么他能把CPU密集型任务做到真正并行。比如图像处理、视频编解码、大规模数值计算——这些场景下如果你用多线程四个CPU核心可能只跑出一个核心的利用率但是用multiprocessing四个核心能接近满载。此外他还能隔离崩溃风险。假如你写了一个可能因为第三方库的C扩展而段错误的程序用一个进程跑任务崩了也只是这个进程退出主程序和其他进程不受影响。这比threading模块安全得多因为线程崩溃往往是整锅端。但注意他并不是万能的。如果是IO密集型任务网络请求、文件读写多线程反而更划算。因为进程的创建开销比线程大得多而且进程间通信IPC需要序列化数据比如用Queue或Pipe这会带来额外的性能损耗。对于大多数Web后端场景asyncio或threading才是更自然的选型。3. 怎么使用一个常见的例子是处理大量图片。假设有1000张图片需要调整尺寸单线程可能需要10秒而用四进程能把时间压到3秒左右。基础用法是这样的frommultiprocessingimportPooldefprocess_image(filename):# 模拟图像处理returnf{filename}processedif__name____main__:filenames[fimg_{i}.jpgforiinrange(1000)]withPool(processes4)aspool:resultspool.map(process_image,filenames)这里Pool就像一个工头把任务分给四个工人进程。pool.map会阻塞主程序直到所有任务完成。如果要更精细控制可以用apply_async配合回调函数。如果任务之间有依赖关系你可能需要直接操作Process类frommultiprocessingimportProcess,Queuedefworker(q,data):resultdata*2q.put(result)if__name____main__:qQueue()pProcess(targetworker,args(q,10))p.start()valueq.get()p.join()这里用Queue传递结果是个好习惯因为它默认做了序列化和进程安全。直接共享内存比如Value或Array虽然快但容易踩到同步问题的坑——除非你非常清楚自己在做什么。4. 最佳实践第一永远把资源初始化放在if __name__ __main__:后面。Windows上没有fork机制会重新导入模块如果不加这个保护每个子进程创建时都会莫名其妙地启动新的进程池形成无限递归。这种错误能把调试体验拉低到地狱级别。第二优先用Pool而不是自己管理进程生命周期。Pool自动维护进程池、处理任务分配。手动管理Process就像自己写线程调度器一样容易在异常处理、资源回收上出问题。比如进程因为异常退出时你得手动检查退出码但Pool会帮你重新启动新进程。第三需要共享数据时用Manager。普通变量在子进程中是独立副本改动了父进程也看不见。Manager提供了一种代理对象比如Manager().list()虽然每次访问都有序列化开销但比手撸Pipe和锁要安全得多。如果对性能有极致要求比如传递numpy数组可以研究shared_memory模块但日常开发还是少碰为妙。第四记得设置maxtasksperchild。当子进程处理大量任务时可能会积累内存泄漏比如第三方库的C扩展缓慢泄露。设置Pool(processes4, maxtasksperchild100)可以在每100个任务后重启进程像定期的垃圾回收一样。5. 和同类技术对比对比多线程threading多线程的创建开销低约50KB内存进程则要数MB多线程共享内存、无序列化开销但受GIL限制只能利用单核。所以CPU密集任务用multiprocessingIO密集用threading。有一个灰色地带混合场景比如先读文件再计算可以用多线程处理IO部分再把计算结果通过concurrent.futures提交给进程池。不过这种方案容易让代码变得像意大利面条一样还不如直接用asyncio的run_in_executor来解耦。对比**concurrent.futures.ProcessPoolExecutor**这实际上是multiprocessing.Pool的封装接口更统一支持as_completed等高级用法。但它的灵活性稍差——比如无法设置maxtasksperchild也不能直接访问Queue。如果只是做简单的map操作用它更优雅需要精细控制时还是需要回到multiprocessing。对比**subprocess**subprocess是启动外部程序比如ffmpeg进程间通过标准输入输出通信。而multiprocessing启动的是Python解释器中的函数。如果你的任务已经有一个现成的命令行工具比如ImageMagick的convert那用subprocess调用比重新用Python写一遍要高效得多。但如果是自定义的计算逻辑显然multiprocessing更自然。对比分布式框架如RayRay做的其实就是把multiprocessing的概念扩展到多台机器上。如果你只有单台服务器multiprocessing更轻量如果服务器有几十核心甚至跨机器Ray能自动处理序列化、调度和容错。不过Ray的学习曲线比multiprocessing陡峭得多项目中要权衡好是否真的需要这种规模。