concurrent.futures.ProcessPoolExecutor进程数限制及Windows报错问询

1. concurrent.futures.ProcessPoolExecutor()的进程数量限制 #

默认情况下，ProcessPoolExecutor的max_workers参数会自动设置为你的CPU核心数（可通过os.cpu_count()查看），这是为了避免过多进程导致CPU上下文切换开销飙升。你也可以手动指定max_workers调整进程数，但实际能创建的进程数还受系统资源约束——比如Windows对同时运行的进程数有隐性限制，过多进程可能引发内存、进程句柄不足等问题。

2. n=10时的报错细节分析 #

为什么部分进程能正常完成？ #

前几个进程能顺利执行，是因为它们在错误触发前已经完成任务并返回结果。你的Core-i7通常是8核，所以默认max_workers=8：当n=10时，进程池先启动8个进程处理前8个任务，剩下2个任务排队等待空闲进程。错误就发生在处理排队任务的阶段——当某个进程空闲后，尝试接收新任务时，序列化函数f出现了身份验证问题。

报错的根本原因 #

这是Windows平台Python的特有问题，根源在于Windows下multiprocessing采用spawn模式创建进程，而非Linux/macOS的fork模式：

• spawn模式下，每个子进程会重新运行你的主脚本，直到if __name__ == '__main__'代码块才停止执行。这意味着子进程会重新定义函数f，生成一个和父进程中f完全不同的对象实例。
• 当进程池复用空闲进程处理新任务时，需要把父进程中的f序列化传递给子进程，但pickle机制会检查子进程中__main__.f是否与父进程中的f为同一对象——显然不是，因此抛出PicklingError。

是否仅在Windows平台出现？ #

是的。Linux和macOS默认使用fork模式创建进程，fork会直接复制父进程的内存空间，子进程中的f与父进程是同一个对象，不会触发这个pickle验证问题。

是否与CPU核心数有关？ #

有关系。默认max_workers等于CPU核心数，当任务数n≤核心数时，所有进程会一次性启动，每个子进程在启动时重新定义f，此时任务传递和执行不会触发进程复用逻辑，因此不会报错；当n>核心数时，进程池需要复用空闲进程处理排队任务，这就触发了pickle身份验证的问题，导致报错。

解决方法 #

你可以通过两种方案解决这个问题：

• 方案一：避免进程复用：手动设置max_workers为大于等于n的值（比如ProcessPoolExecutor(max_workers=10)），让所有任务都能一次性启动新进程处理，跳过复用逻辑。
• 方案二：将函数移到独立模块：把函数f放到单独的Python模块（比如utils.py），再在主脚本中导入。这样子进程导入的是模块中的f，而非主脚本中重新定义的版本，pickle就能正常识别函数身份。

方案二示例：

1. 创建utils.py：

def f(x):
    lo = 0
    for i in range(x):
        lo += i
    return lo

2. 主脚本修改为：

import time
import concurrent.futures
from utils import f

n = 10
if __name__ == '__main__':
    t1 = time.perf_counter()
    with concurrent.futures.ProcessPoolExecutor() as executor:
        Ans = [executor.submit(f, 10**7-i) for i in range(n)]
        for future in concurrent.futures.as_completed(Ans):
            print(future.result())
    t2 = time.perf_counter()
    print('completed at', t2-t1, 'seconds')

这样修改后，无论n设置为多少，都不会再出现pickle错误。

内容的提问来源于stack exchange，提问作者AmirHosein Sadeghimanesh