多进程编程不是银弹而是天坑这7个致命误区你踩了吗这段时间, 我花费了好些时间去钻研多进程编程, 查阅了官方文档, 浏览了 Stack 的讨论内容, 还研读了几篇技术博客, 结果发觉网上教程多数都在讲述基础用法, 然而真正进入实战阶段麻烦接连不断。这份内容是我自行整理出来的一份实战纲目, 着重指明那些容易被忽视的地方, 不弄些华而不实的术语就是讲大白话。先讲讲对于并行的理解, 好多人认为多进程是用来突破GIL的, 可是CPU核数与能跑的并行数并非同一回事, 超线程跟物理核心有差异, 多进程若真的占用一个物理核心, 那切换进程的开销比切换线程大好多, 我做过在8核机器上跑测试这事, 多线程及多进程的CPU占用率曲线相差众多, 有的时候多进程反倒更缓慢。比如说, 存在高I/O任务这种情况, 多进程所有的额外开销, 也就是进程创建、序列化以及进程间通这些内容加在一起, 有可能把并行带来的好处淹没掉呢。就我自己而言, 曾经写过代码进行测量, 发现任务类型对于加速比起着很大作用。得出的结果就是, 多进程并非万能的解决办法, 选用它与否必须依据你的任务计算密度以及数据处理量来决定。另外, 多进程存在一个这样的优点, 那便是其隔离性很强, 就算有一个进程崩溃了, 也不会导致整个程序崩溃, 可是在线程当中却无法做到这一点。谈及设计哲学, 好多人写多进程代码时依旧在琢磨共享状态, 实际上官方更倾向于采用队列来传递消息。共享内存Value/Array存在隐形成本, 像是锁争抢、类型限制、内存对齐等情况, 要是运用不当反倒会更慢。队列能够自然地解耦, 还能够控制背压, 其序列化边界也很清晰。我对Go的队列进行过对比, 它存在不足, 不过添加个就能弥补上。进程间通信存在着四种常见的模式 ,分别有所适用场景, 通过示例说明, 单向流水借助Queue来实现, 这种模式比较适合生产者消费者场景, 然而当任务量幅度颇为巨大的时候, 队列就会面临内存溢出的状况 , 双向单通道借助Pipe来达成, 适用于父子进程间进行简单对话的情景, 只是倘若半双工使用不当就会引发死锁的现象 , 共享小块数据运用Value/Array来达成, 适合用于计数器或者状态标志的适用情形, 不过必须要配合锁来使用 , 大块数处于零拷贝的状态时可以在某种条件下使用, 此条件为基于3.8以上的版本, 适用于图像或者大数组的情景状态, 但若生命周期管理出现问题就会麻烦不断, 还容易引发内存泄漏的情况。一种反模式必须要绕行避开, 即别去琢磨共享对象。全局变量于子进程里是被复制过去的, 并非是实际意义上的真正共享。一旦有人在继承之后修改类属性, 那实际上属于伪共享。正确的做法是运用代理复杂对象, 然而代价是性能会损失10到100倍, 可以视具体情况进行权衡取舍。在实战当中, 你将会遭遇到七个隐形的杀手。其中第一个为进程创建时存在的三重开销, fork以及spawn在Linux之上区别是非常大的, 子进程会对父进程的地址空间进行复制, 而COW机制并非是免费的。要是一次性创建100个进程, 系统很可能会卡住, 最好更换为进程池。第二个存在的是序列化陷阱, 为何对函数传递进行了限制呢, 而是因为该语境下对序列化加以了限制, 导致内部函数、C扩展以及部分类均无法得以传递,针对这一状况的解决方案为采用, 或者重新去构建设计数据结构, 全部都运用纯数据, 常见出现的报错为“: Cant local ”, 其问题根源恰恰源自于此环境。第三步是特别注意的事项, 有着强制性的要求, 写作if , 这是由于采用了spawn模式, 在此处多进程会失去效力, 能够替换成。..。第四个情况是守护进程出现了误用的状况, True这种情况会致使子进程猝然终止, 并且资源未能得到释放, 最佳的做法是手动发送终止信号, 同时配合join()实现优雅地退出。经过进一步的优化, 能够使得多个进程运行的精准程度如同精密的瑞士手表一般。进程池是需要进行深度的调整优化的, Pool 和各有着不同的适用场景所在。参数对于负载均衡是有着影响作用的, 面对大数据集需要划分区块处理。应用配合回调的方式能够实现动态扩容, 进而达成混合模型。任务优先处理的实现方式, 是使用异步和多进程混搭这种隐藏用法, 加就能绕过GIL。真实案例像爬虫框架, 异步I/O加多进程解析, 架构清晰, 这就是其具体体现。内存共享的最终极解决方案为, 无需进行序列化操作, 而是直接让多个进程去访问同一块物理内存。与numpy配合来做并行矩阵乘法, 速度提升幅度近乎接近内核数。但需留意不存在自动垃圾回收机制, 必须要显式进行操作。进程中间的锁同样是存在优化策略的, 使用RLock去替代Lock是能够允许同一进程有着重入这一情况的, 条件变量具备可以精确唤醒的能力, 于此种情况下能够避免忙乱等待的状况发生, 锁的粒度是需要去寻找到平衡的, 要是使用粗锁就会致使串行的出现, 而要是使用细锁则会增加开销的。架构模式于从玩具代码迈向生产级的过程中颇为重要。其如工厂流水线, 每个进程承担一个阶段, 这般适合流式数据。它能分而治之, 之后汇总结果之处, 适合独立任务。究竟选哪个, 得看任务之间是否存在依赖关系才确定。日志处理以及异常处理绝不能够被轻视, 子进程所出现的异常状况需要进行捕获操作 , 并且传递至主进程那里, 日志必须要打上pid标识, 以此来避免出现混乱现象。.()做多进程安全日志。监控具备相应作用, 测试同样有着实用价值。通过监控子进程的CPU使用情况以及内存占用状况, 进而实现对进程数进行动态调整。单元测试具备能够模拟出某些陷阱的能力, 依托.mock取代真实进程这一方式方法。在稳定性层面采取设置措施, 以此来防止内存泄漏不断累积。最后提及一番替代方案, 有时不采用反倒更佳, 像分布式任务队列或者RQ, 可跨机器、能持久化、存在重试机制。相较于多进程而言, ray框架更快还更易于使用, 适配AI场景, 着重于科学计算, 自动处理序列化。总括而言, 一张用于决策的速查表颇具效用, 依据任务的类型来挑选方案, 预期的加速比届时也会心中有数。最后的告诫是: 率先撰写正确的单进程版本, 借助工具开展性能分析, 最终再判定是否要进行并行处理。我个人做过三个实验: 对比多线程以及多进程运算斐波那契数列, 仿真生产者消费者去读取100MB文件, 运用进程池加去实施图像批量滤镜。完成这些之后, 对于多进程的理解便笃定许多了。