Python多进程核心是绕过GIL并行计算，需掌握fork/spawn启动差异、IPC选型（Queue/Pipe/Value/Manager）、资源管理及避免嵌套进程等陷阱；实测图片缩略图处理提速7倍。
Python多进程的核心在于绕过GIL（全局解释器锁），真正利用多核CPU并行执行计算密集型任务。关键不是“开多个Process”，而是理解进程创建、通信、同步与资源管理的底层逻辑。
进程启动方式与fork/vspawn差异
在Unix/Linux系统中，fork是默认启动方式：子进程复制父进程内存空间（写时复制），速度快但可能引发意外状态继承（如已打开的文件描述符、线程锁）；Windows和macOS默认用spawn：重新导入主模块、逐个初始化，更干净但启动稍慢、要求脚本必须有if __name__ == '__main__':保护。
- 显式指定启动方式：
mp.set_start_method('spawn')（需在if __name__ == '__main__'内调用） - 调试时遇到“RuntimeError: An attempt has been made to start a new process before the current process has finished its bootstrapping phase”——大概率是没加
if __name__ == '__main__'或跨平台混用逻辑
进程间通信（IPC）选型指南
不要一上来就用Queue或Pipe，先看数据特征：
-
小量、无序、生产-消费模型 →
multiprocessing.Queue（线程/进程安全，内部用Pipe+后台线程） -
高速、点对点、双向流式数据 →
multiprocessing.Pipe()（比Queue轻量，但不支持多生产者/多消费者） -
共享简单变量（int/float/bool） →
multiprocessing.Value或Array（底层映射到共享内存，无需序列化） -
需要复杂对象或跨进程一致性视图 →
multiprocessing.Manager()（启动独立服务进程，支持dict/list等，但有网络开销）
避免常见陷阱的实战要点
多进程不是万能加速器，错误使用反而更慢甚至崩溃：
- 频繁传递大对象（如DataFrame、大列表）→ 序列化/反序列化开销远超计算收益，改用
Value/Array或文件+路径传递 - 子进程内再开进程（如嵌套
Pool）→ 可能触发系统级限制或死锁，一律用单层池 + 合理任务粒度 - 忘记关闭资源 → 子
进程中的数据库连接、文件句柄、GPU上下文不会自动释放，务必用try/finally或上下文管理器 - 日志混乱 → 各进程写同一文件会错乱，用
logging.handlers.QueueHandler统一转发到主进程记录
进程中的数据库连接、文件句柄、GPU上下文不会自动释放，务必用一个真实可运行的优化案例
处理10万张图片缩略图（I/O+CPU混合）：
- 不用
ThreadPoolExecutor（GIL限制CPU部分） - 不用粗粒度单进程遍历 → 改为
ProcessPoolExecutor(max_workers=cpu_count()-1) - 每任务只传文件路径，结果用
Queue收集失败项，成功路径写入临时文件避免IPC瓶颈 - 主进程监控进度：用
concurrent.futures.as_completed()实时打印完成数，不阻塞
实测在8核机器上，耗时从单进程12分钟降至1分40秒，提速约7倍，且内存峰值下降30%。
