Python的Pool采用主-从协作+懒加载+任务队列缓冲方式动态分发任务：任务先入共享任务队列，子进程主动拉取执行；结果通过独立结果队列返回主进程。
Python 的 Pool 并不是把任务“平均切分”后一次性发给所有进程，而是采用**主-从协作 + 懒加载 + 任务队列缓冲**的方式动态分发任务。
任务提交时并不立即分发
调用 pool.map()、pool.apply_async() 等方法时，任务只是被放入 Pool 内部的 共享任务队列（task queue），由主进程维护。此时子进程可能还在初始化或空闲等待，并未收到任何任务。
-
map()会先把可迭代对象转为任务列表，逐个放进队列，但不阻塞等待执行 -
apply_async()每调一次就放一个任务进队列，完全异步 - 队列底层基于
multiprocessing.Queue，线程/进程安全，支持跨进程通信
子进程主动从队列中“拉取”任务
每个子进程启动后，会进入一个循环：持续尝试从任务队列中 阻塞式获取（get()） 下一个任务。一旦拿到，立刻执行；执行完再回去取下一个——这是典型的“工作窃取”简化版，无需主进程调度干预。
- 没有中央调度器分配任务，避免单点瓶颈
- 空闲进程自动获取新任务，天然负载均衡
- 若队列为空且主进程已关闭（如
close()后无新任务），子进程会退出循环并终止
chunksize 影响实际分发粒度
在 map() 和 starmap() 中，可通过 chunksize 参数控制每次从可迭代对象中取出多少项打包成一个子任务发送到队列。默认值由 len(iterable) // (4 * processes) 估算，目的是减少 IPC 开销。
立即学习“Python免费学习笔记（深入）”；
-
chunksize=1：每个元素单独成任务 → 队列操作频繁，适合计算密集且单次耗时长的任务 -
chunksize=100：每 100 个元素打包一次 → 减少通信次数，适合大量轻量级任务 - 手动设过大可能导致某进程长期占用、其他进程空闲（尤其数据不均时）
结果收集也走队列，但方向相反
子进程执行完任务后，把结果（或异常）序列化，通过另一个 结果队列（result queue） 发回主进程。主进程在调用 get()（如 async_result.get()）或 map() 返回时，才从该队列中按顺序或超时等待取结果。
- 结果队列也是 multiprocessing.Queue，独立于任务队列
-
map()返回前会隐式等待全部结果，相当于对每个 chunk 调用get() - 若某个子进程崩溃，其未返回的结果会卡住等待，触发超时或异常（取决于调用方式）
