Python 进程池异常 怎样处理

Python 进程池报错时，先别急着把 try/except 套在提交任务的那一行。最常见的情况是：异常发生在子进程里，主进程只有在 AsyncResult.get() 或 Future.result() 取结果时才重新收到它；如果 worker 根本没有正常启动，则要查入口保护、参数序列化或进程池本身是否已经损坏。

先判断异常到底发生在哪一层

可以把一次调用拆成四段：主进程提交参数、worker 导入并执行函数、结果回传、主进程读取结果。每段失败的证据不同。

Pool 任务异常要在 get 或 error_callback 处处理

apply_async 返回的是结果对象，不代表任务已经成功。任务函数抛出的异常会在 get() 时重新抛出；如果只提交不取结果，主进程就可能错过失败信号。需要统一记录失败任务时，可以使用 error_callback：

from multiprocessing import Pool

def parse_item(item):
    # 用明确的输入校验，让坏数据在 worker 内快速失败
    if not isinstance(item, str):
        raise TypeError("item 必须是字符串")
    return item.strip().upper()

def on_error(exc):
    # 回调只做轻量记录，避免阻塞结果处理线程
    print(f"worker 任务失败: {type(exc).__name__}: {exc}")

if __name__ == "__main__":
    # 上下文管理器负责在退出时回收进程池
    with Pool(processes=2) as pool:
        results = [pool.apply_async(parse_item, (item,), error_callback=on_error)
                   for item in ["ok", 7, "done"]]
        for result in results:
            try:
                # get 是把子进程异常带回主进程的观察点
                print(result.get(timeout=5))
            except Exception as exc:
                # 继续处理其他结果，但保留当前任务的失败记录
                print(f"主进程收到异常: {type(exc).__name__}: {exc}")

这里的两层处理不是重复捕获：error_callback 适合集中记录，get() 适合让调用方决定跳过、降级还是终止批次。回调本身应尽快返回，重试、写大文件等操作不要塞进去。

ProcessPoolExecutor 用 Future 保留任务上下文

如果任务需要携带输入编号，ProcessPoolExecutor 的 Future 更容易和业务上下文配对。异常通常在 future.result() 时出现，因此提交阶段的 try/except 不能替代取结果阶段的处理：

from concurrent.futures import ProcessPoolExecutor, as_completed

def calculate(value):
    # 只传递可序列化的简单参数，避免 worker 启动后才失败
    if value 

函数应定义在模块顶层，参数和返回值应能被 pickle；交互式解释器里的临时函数、lambda、打开的文件对象或带锁对象，都可能导致提交或执行失败。

遇到 BrokenProcessPool 或超时怎样收尾

BrokenProcessPool 表示 worker 非正常终止，和某个任务主动抛出 ValueError 不同。此时继续向同一个池提交任务通常没有意义。先保留异常上下文，退出 with 或显式 shutdown，再检查 worker 的启动日志、操作系统终止信号、内存压力和初始化函数。

超时也不要直接当成任务失败重投：任务可能仍在执行，重复提交会造成重复写入。对具有幂等键的任务才考虑有限次数重试；对不可重试的副作用任务，应先查询任务状态。

延伸问答：哪些异常不能靠重试解决

为什么子进程里的 print 看不到完整堆栈？

多个进程共用输出时，文本可能交错；更可靠的做法是让主进程在 get() 或 result() 处统一记录异常类型、任务参数和任务 ID。

为什么加了 try/except 仍然出现进程池报错？

常见原因是只包住了提交阶段，没有包住结果读取阶段；另一种情况是 worker 启动或序列化失败，异常发生在任务函数执行之前。

什么时候应该重建进程池？

只有确认旧池已损坏、资源已回收并且任务具备幂等性时才重建。若根因是不可 pickle 的参数、缺少 __main__ 保护或输入数据本身，先修复根因再重试。