相同Python配置下multiprocessing在两台机器运行结果不一致是什么原因

• 确认多进程启动方式是否一致
  不同操作系统的Python默认多进程启动逻辑存在差异，Linux默认使用fork，Windows、新版macOS默认使用spawn，两种模式下进程的生命周期判断逻辑存在区别。
  先在两台设备分别执行如下代码查看默认启动方式：

  import multiprocessing
  print(multiprocessing.get_start_method())
  

  若结果不一致，在你的业务代码开头统一指定启动模式即可：

  if __name__ == "__main__":
      multiprocessing.set_start_method("spawn", force=True)
      # 后续业务代码放在该guard下
  

  注意Windows系统下所有多进程代码必须放在if __name__ == "__main__":代码块内，否则会出现进程重复启动、无法正常退出的问题。

• 补充进程终止后的资源回收逻辑
  你当前的代码调用p.terminate()后没有回收进程资源，部分系统下已终止但未被父进程回收的僵尸进程会被is_alive()误判为存活状态。修改代码在terminate()后补充一次join操作：

  if p.is_alive():
      print('timed out on 10 sec limit, trying again...')
      p.terminate()
      p.join() # 新增这行回收进程资源
  

• 验证最小复现用例排除业务函数隐性问题
  单独运行sngl_quote正常不代表多进程场景下无异常，使用如下最小测试用例验证多进程基础逻辑是否正常：

  import multiprocessing
  import time
  
  def test_dummy():
      # 模拟执行3秒就结束的函数
      time.sleep(3)
  
  if __name__ == "__main__":
      p = multiprocessing.Process(target=test_dummy)
      p.start()
      p.join(10)
      print(f"进程是否存活：{p.is_alive()}")
  

  如果该用例在两台设备输出结果不同，说明新设备的Python编译环境存在缺陷：你可以尝试用pyenv重新编译安装Python 3.8.6，编译前先安装对应系统的Python编译依赖（比如Debian/Ubuntu系的build-essential libffi-dev libssl-dev zlib1g-dev，macOS的Xcode命令行工具）。如果该用例输出一致，说明sngl_quote内部存在多进程场景下的隐性依赖，比如和父进程共享了未正确复制的网络连接、文件句柄等资源，需要针对该函数的具体逻辑排查。

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