Ubuntu下multiprocessing调用Scipy优化与DBSCAN时进程挂起

问题概述 #

在Python中使用Scipy的SLSQP优化方法时，为加速雅可比矩阵计算，通过multiprocessing.Pool并行化代价函数，而代价函数内包含Scikit-learn的DBSCAN聚类算法。出现以下异常：

• 仅在Ubuntu环境下，使用multiprocessing并行时进程挂起；Windows环境无此问题
• 使用ThreadPool替代multiprocessing.Pool时，Ubuntu环境也能正常运行
• 挂起发生在子进程执行DBSCAN的fit方法阶段，从控制台输出可见子进程打印了Running cost function for x: [0.5 0.5]后无后续输出

环境差异的影响 #

Windows和Ubuntu的进程创建机制差异是核心因素：

• Windows：默认使用spawn方式创建子进程，会重新加载Python解释器并导入所有模块，子进程拥有独立的运行环境，父进程的OpenMP/BLAS并行配置不会被继承。
• Ubuntu（类Unix系统）：默认使用fork方式创建子进程，子进程会直接复制父进程的内存空间和所有运行状态，包括父进程中已初始化的OpenMP线程池、BLAS的并行配置。

挂起的核心原因 #

你的推测完全正确，问题源于嵌套并行与资源竞争：

1. Scipy与BLAS的并行：Scipy的优化底层依赖BLAS库（如OpenBLAS、MKL），这些库默认启用多线程并行。
2. DBSCAN与OpenMP的并行：Scikit-learn的DBSCAN在计算邻域时，会使用OpenMP进行多线程加速——即使测试数据规模很小，OpenMP的线程池初始化逻辑依然会触发。
3. fork+嵌套并行的冲突：
   • Ubuntu下multiprocessing.Pool用fork创建子进程时，子进程复制了父进程已有的OpenMP/BLAS线程池状态。
   • 子进程执行DBSCAN时，尝试初始化自身的OpenMP线程池，此时与继承自父进程的线程池产生资源竞争或死锁：OpenMP的线程管理在fork后的子进程中存在兼容性问题，子进程无法正确初始化或调度线程，最终导致进程挂起。
4. ThreadPool无问题的原因：ThreadPool使用线程而非进程，所有线程共享同一个进程空间，OpenMP/BLAS的线程池可以正常复用，不会出现资源竞争或死锁。

验证与解决方案 #

可以通过以下方式验证并解决问题：

• 禁用OpenMP多线程：在代码开头添加环境变量设置，强制DBSCAN使用单线程：

  import os
  os.environ["OMP_NUM_THREADS"] = "1"
  

• 改用spawn进程创建方式：在Ubuntu下强制multiprocessing使用spawn，模拟Windows的进程隔离逻辑：

  from multiprocessing import set_start_method
  if __name__ == "__main__":
      set_start_method("spawn")
      x0 = np.array([0.5, 0.5])
      print("Starting optimization...")
      result = minimize(cost_function, x0, method='SLSQP', jac=gradient_function)
      print("Optimization result:", result)
  

• 避免嵌套并行：如果雅可比矩阵计算的并行需求不高，可直接使用单进程计算；或在父进程中提前将BLAS/OpenMP的线程数设置为1，避免子进程继承多线程配置。

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