前面讲了进程创建与进程通信的内容,接下来讲一下多进程编程最能发挥的地方。对于同时运行多个同质任务来讲,采用multiprocessing.Pool
进程池去管理是最方便的。Pool
的用法如下:
1 | from multiprocessing import Pool, process |
打印出来的结果,可能是这样子的:
1 | [<SpawnProcess name='SpawnPoolWorker-4' pid=7648 parent=2468 started daemon>, |
我们可以在结果中看到这样的景象:
- 当进入
with Pool
代码段时,进程池中的进程已经被预先创建了 - 总共16个任务,最后却只在进程池里单独1个进程中运行(小概率在2个进程中运行)
具体缘由,我们一起来看Pool
的代码实现。
1 | class Pool(object): |
一个Pool
实例总共包含以下的内容:
self._processes
:所有worker子进程实例self._worker_handler
:管理worker子进程的线程self._task_handler
:任务调度线程self._result_handler
:结果收集线程
上述所有的worker
子进程跟管理线程在初始化的时候,都会被启动。首先我们来看worker
进程的情况:
1 | def _repopulate_pool(self): |
_repopulate_pool
是启动所有worker
进程的出发点,顺流而下,所有worker
进程最终会执行worker
函数。worker
函数有如下的步骤:
- 执行
initializer(*initargs)
。在多进程的场景下,有很多模块到了子进程可能是未初始化的状态,而initializer
就提供了一个在子进程中初始化某些模块或者变量的途径。 - 从
inqueue
中get
一个task
的实例,将其unpack
- 执行
task
中的func
,得到结果 - 将结果
put
到outqueue
然后我们再看下_task_handler
,对应的函数是Pool._handle_tasks
1 |
|
task_handler
负责从taskqueue
中得到task
实例,并put
到inqueue
中。当所有task
实例推送完毕后,像result_handler
和所有worker process
推送了None
实例。从先前worker
的代码中可以知晓,当inqueue
收到了None
,就代表任务已经推送完毕,可以break
退出了。而至于为何也给到result_handler
一个None
实例,我们就看下result_handler
的代码,来分析其中具体的机制。
1 |
|
在handle_results
的主循环中,会不断地从outqueue
里get
结果,然后放到cache
中。参考worker
进程的实现中我们可以知晓,从outqueue
里获取的结果即是worker
任务执行后的返回值。
当所有task
在handle_tasks
线程被消费完之后,handle_tasks
线程会在outqueue
里put
一个None
值。handle_results
线程接收到None
值后,直到cache
为空或者Pool
被终止(TERMINATE)为止,都会继续接收子进程任务执行结果并存到cache
里。cache
为空或者Pool
被终止之后,handle_results
线程会清空outqueue
,然后退出。
从worker
、task
、result
线程的作用可以看到,inqueue
、outqueue
、cache
是连接用户业务线程和子进程之间的桥梁。inqueue
和outqueue
的作用在前面的叙述中已经非常清楚,一个用来上传任务,一个用来下发执行结果。因此最终,我们还是要深入研究一下cache
的运行机制。
首先我们还是回顾一开始给的例子,test_pool
函数:
1 | def test_pool(): |
test_pool
函数调用了starmap
,starmap
方法需要给定一个任务函数以及一组参数,和map
不同的是,starmap
指代的参数是带星的(*args
),因此在调用任务函数时会unpack
对应的参数。
starmap
之后,涉及到的方法定义如下:
1 | def starmapstar(args): |
各类map/map_async
方法,最终都会落实到_map_async
方法。在_map_async
方法中会做以下几件事情:
- 计算
chunksize
,即每batch
子任务的数量 - 通过
_get_tasks
函数,获取传递子任务batch
的generator
- 生成
MapResult
实例result
- 在
taskqueue
中放入_guarded_task_generation
的任务generator
实例
每个子进程最终会调用mapper(task_batch)
,相当于是list(itertools.starmap(func, task_batch))
,也就是单个子进程会执行一个batch
的任务,然后返回一组这个batch
的执行结果。
从这个角度推论,假设每个任务函数执行要1s,总共16个子任务,chunksize
是14,pool
的size
是2,那么一执行起来,前2秒的话2个子进程都会打印执行结果,然后接下来12秒就只有第1个子进程打印结果了。这是因为,第1个子进程一批被分了14个,第2个子进程一批就被分了剩下2个。如果其它变量不变,pool
的size
是3,那么打印的效果也和size
为2的时候一样,这是因为chunksize
太大,前2个子进程已经瓜分了所有子任务(14、2),第3个子进程啥任务都分不到了。
所以chunksize
的设定,也是一门学问。实际使用pool
的时候要注意这个坑。
接下来注意力转到MapResult
实例result
上,也是在这个地方会对任务缓存cache
做一些操作。首先我们看MapResult
的定义:
1 | job_counter = itertools.count() |
针对starmap
而言,在worker
中,执行了一批子任务之后,会调用put((job, i, result))
返回独立的job_id
、任务组编号、子任务批次的结果集。我们需要注意到,在result
初始化时侯,会通过[None] * length
占位所有的结果(self._values
),并且在缓存中设置本次job
(ApplyResult
中self._cache[self._job] = self
),然后在handle_results
线程中_set
结果时,调用了MapResult._set
,会根据任务组编号i
把对应位置的结果替代。直到所有批次的结果集执行结果返回后,最终会清楚缓存中的这次starmap
的job_id
,然后调用self._event.set()
starmap
函数会阻塞,直到所有结果返回。实现阻塞操作的方式,即是用了threading.Event()
。starmap
返回的是result.get()
,在get
的实现里,会调用self._event.wait
,也就是阻塞,直到self._event.set
。这样,只有所有结果返回,starmap
才会返回。如果大家日常开发中,有这种等待直到执行成功的业务需求,不妨尝试用threading.Event()
,比sleep
轮询的方式优雅的多。
说到底,Pool
为多进程编程提供了灵活的任务调度模型。日常如果需要用到进程池做并行操作,用原生的multiprocessing.Pool
就是不二选择。
当然,并行任务还有一种选择方案实用ProcessPoolExecutor
,比原生的Pool
稍微轻量级一点。ProcessPoolExecutor
的机理实现,也可以参考这篇文档。