ProcessPoolExecutor基于multiprocessing构建进程池，通过submit/map提交任务并返回Future对象，复用子进程执行CPU密集型任务以绕过GIL限制。
ProcessPoolExecutor 的核心原理是：用固定数量的子进程预先构建一个“池”，任务提交后由空闲进程自动领取执行，避免反复创建销毁进程的开销；它基于 multiprocessing 模块封装，但通过 concurrent.futures 提供统一、简洁的高层接口，内部用 Future 对象管理每个任务的状态和结果。
底层依赖 multiprocessing，但做了关键抽象
它不是从零实现进程管理，而是以 multiprocessing.Pool 为底座，重写了任务分发、结果收集、异常传递等逻辑。区别在于：
- 不暴露
apply/apply_async等低层方法，只保留submit和map两种主流提交方式 - 每个任务返回一个
Future实例，状态（运行中/完成/失败）可查，结果可延迟获取 - 自动处理进程启动、通信序列化（通过 pickle）、资源回收（退出时自动
join）
任务如何被分发和执行
当你调用 executor.submit(func, *args) 时：
- 参数和函数名被序列化，通过管道或队列发送给空闲工作进程
- 工作进程反序列化后执行函数，把结果（或异常）再序列化传回主进程
- 主进程中的
Future对象被标记为完成，并缓存结果，result()调用时直接返回
而 map 是批量提交的语法糖，本质是循环调用 submit，但结果按输入顺序迭代返回（注意：不是执行顺序）。
立即学习“Python免费学习笔记（深入）”；
进程复用与生命周期管理
进程池不会为每个任务新建进程，而是维护一组长期存活的工作进程：
- 初始化时根据
max_workers参数启动指定数量的子进程（默认为 CPU 核心数） - 进程启动后进入等待状态，监听任务队列；任务完成后不退出，继续等待下一个任务
- 使用
with语句或显式调用shutdown(wait=True)时，才向所有工作进程发送退出信号并等待其结束
为什么适合 CPU 密集型任务
因为 Python 的 GIL（全局解释器锁）会阻塞多线程的并行计算，但进程间互不共享内存，每个子进程有独立的 GIL 和解释器实例：
- 数学运算、图像处理、加密解密等纯计算任务能真正并行执行
- 进程间数据传递有开销（序列化/反序列化），所以不适合高频小任务，而适合单次耗时较长的任务
- 若任务含大量 I/O，反而推荐
ThreadPoolExecutor或asyncio
