17370845950

应使用Manager、Queue或Pipe实现进程间安全数据传递；优先选Manager.list()/dict()收集少量结果，高吞吐用Queue；避免直接修改普通list/dict；推荐apply_async+callback异步聚合；需控制进程数、chunksize及maxtasksperchild优化资源；务必规范生命周期管理并捕获异常。

进程池中如何安全传递数据

多进程环境下，全局变量无法共享，子进程修改不会影响主进程。想让子进程结果回传，得用 Manager、Queue 或 Pipe 这类跨进程通信机制。

推荐优先使用 multiprocessing.Manager().list() 或 dict()：语法接近原生类型，适合收集少量结构化结果；若需高吞吐或流式处理，用 Queue 更合适——它线程与进程安全，且支持阻塞/超时控制。

• 避免直接往普通 list/dict 写数据：看似成功，实则每个子进程操作的是自己内存副本
• Manager 对象有额外序列化开销，别用它存大数组或图像等二进制数据
• Queue.put() 和 get() 默认阻塞，生产环境建议加 timeout 防卡死

用 apply_async + callback 实现异步结果聚合

比起 map() 的同步等待，apply_async() 更灵活：任务提交后立即返回 AsyncResult 对象，配合 callback 参数，可在子进程完成时自动触发主进程中的函数，无需轮询或手动 join。

典型场景是批量下载+解析：每个子进程抓取一页并解析出标题和链接，callback 负责把结果 append 到 Manager.list()，主进程继续提交新任务，不空等。

• callback 函数必须接受一个参数（即子进程 return 的值），不能带额外参数
• callback 在主进程中执行，所以可安全操作文件、数据库或全局状态
• 若需错误处理，用 error_callback 捕获子进程异常，避免整个池被中断

限制内存与 CPU 的实用优化技巧

默认 Pool() 启动进程数等于 CPU 核心数，但实际瓶颈常在 I/O 或内存——比如同时开 16 个浏览器实例跑 Selenium，内存瞬间爆满。

优化方向有两个：一是用 maxtasksperchild 控制单个进程处理任务上限，防止内存泄漏累积；二是结合 chunksize 调整 map 类方法的数据分片粒度，减少 IPC 频次。

• IO 密集型任务（如 HTTP 请求）可设进程数为 CPU 数 × 2～4，提升并发利用率
• 内存敏感任务（如图像处理）应显式指定 processes=2 或更低，并监控 RSS 使用量
• 对超长可迭代对象（千万级列表），增大 chunksize（如 1000）能显著降低 Queue 压力

进程池生命周期管理与异常恢复

真实项目中，子进程可能因段错误、第三方库崩溃或 OOM 被系统杀死。不处理会导致 Pool 卡住或后续任务静默失败。

关键做法：调用 pool.close() 禁止新任务，再用 pool.join() 等待完成；异常捕获要覆盖 submit 层和 callback 层；必要时用 pool.terminate() 强制清理僵尸进程。

• 用 try/finally 确保 close/join 总被执行，避免资源泄露
• 子进程内尽量用 logging 而非 print，输出才不会乱序或丢失
• 对关键任务，可在 callback 中写入临时结果文件，主进程启动时先读残留文件做断点续传