Python multiprocessing Pool无明显原因停滞问题求助

问题代码 #

def some_function():
  pass

class SomeClass:
  def __init__(self):
    self.pool = mp.Pool(10)
  def do_smth(self):
    self.pool.map(some_function, range(10))


if __name__ == '__main__':
  cls = SomeClass()
  for _ in range(1000):
    print("*")
    cls.do_smth()

问题现象 #

实际运行的任务远比示例繁重，脚本运行一段时间后无明显原因陷入停滞：无错误报告，终端显示脚本仍在运行，但不再打印"*"，电脑CPU使用率仅3%，内存占用维持在70%左右。设备为24核GPU、32GB内存的MacBook Pro M1 Max。

可能原因及解决方向 #

• 多进程池任务阻塞/死锁
  pool.map是阻塞式调用，如果some_function存在未处理的异常、共享资源（文件/锁）未正确释放，或者子进程意外挂起，主进程会一直等待子进程返回，最终陷入停滞。可以替换为imap/imap_unordered并添加超时机制，同时在子进程代码里强制捕获所有异常，确保任务能正常收尾。另外M1芯片的ARM架构对fork模式的多进程兼容性有限，初始化进程池时建议指定mp_context=mp.get_context('spawn')，避免继承父进程资源引发的问题。

• 子进程资源泄漏
  内存占用稳定不代表没有其他资源泄漏，比如文件句柄、网络套接字等。如果some_function里打开了资源但未关闭，长期运行后会耗尽系统资源，导致子进程无法执行新任务。可以用lsof工具查看进程打开的文件句柄数量，排查是否有持续增长的情况。另外不要长期持有固定进程池，考虑每次任务后关闭池、下次任务重新创建，或者定期重启进程池，避免子进程长期运行积累问题。

• 进程池大小与调度问题
  M1 Max有10个性能核+4个能效核，当前进程池设为10可能和核心数不匹配，过多或过少的进程都会增加调度开销。可以尝试调整进程池大小（比如设为12左右），让进程调度更贴合硬件特性。另外如果some_function是CPU密集型任务，要确保代码能正确释放GIL，避免单进程占用核心导致其他进程无法调度。

• 系统层面限制
  macOS对进程数、线程数有默认限制，可通过sysctl kern.maxproc查看当前最大进程数，检查是否接近上限。另外如果使用的是x86版本Python（通过Rosetta翻译运行），可能存在兼容性问题，建议切换为原生ARM版本的Python。

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