当使用 multiprocessing 并行执行 cpu 密集型 numpy 运算（如矩阵求逆）时，性能反而随进程数增加而急剧下降，主因是 numpy 底层 blas 库（如 openblas、mkl）默认启用多线程，导致每个子进程内部又启动多个线程，引发严重的 cpu 资源争抢与上下文切换开销。
当使用 multiprocessing 并行执行 cpu 密集型 numpy 运算（如矩阵求逆）时，性能反而随进程数增加而急剧下降，主因是 numpy 底层 blas 库（如 openblas、mkl）默认启用多线程，导致每个子进程内部又启动多个线程，引发严重的 cpu 资源争抢与上下文切换开销。
这种现象并非 multiprocessing 本身的问题，而是典型的嵌套并行（nested parallelism）冲突：外层由 Python multiprocessing.Pool 管理的进程级并行，与内层由 NumPy 自动触发的线程级并行（通过 BLAS/LAPACK 实现）相互干扰。尤其在多核服务器上，若未显式限制 BLAS 线程数，每个子进程可能独占全部 CPU 核心（例如 32 核机器上，4 个进程 × 每个进程 8 线程 = 32 线程），造成严重资源竞争——表现为单个任务耗时从 3 秒飙升至 95 秒，且系统负载（load average）远超物理核心数（可用 htop 或 uptime 验证）。
✅ 根本解决方案：禁用或严格限制 NumPy 的底层线程并行，确保「进程数 × 每进程线程数 ≤ 物理 CPU 核心数」。推荐两种可靠方式：
方案一：使用 threadpoolctl（推荐 ✅）
动态、安全、进程内生效，无需修改环境变量或导入顺序。需在每个子进程的函数内部调用（不能只在主进程设置）：
from threadpoolctl import threadpool_limits
import numpy as np
import numpy.linalg as la
def pool_func(number: int, max_number: int) -> dict:
pid = str(multiprocessing.current_process().pid)
print(f'[{number:2d}/{max_number:2d} {pid}] Starting ...')
t0 = time.time()
# ? 关键：在计算密集区强制 BLAS 使用单线程
with threadpool_limits(limits=1, user_api='blas'):
n = 1000
for _ in range(50):
u = np.random.randn(n, n)
v = la.inv(u) # 此处调用的 LAPACK/BLAS 将仅用 1 线程
t1 = time.time()
print(f'[{number:2d}/{max_number:2d} {pid}] Finished in {t1 - t0:.1f} seconds.')
return {}⚠️ 注意：
threadpool_limits的作用域仅限于with块内，且必须在子进程中调用（如pool_func内）。主进程设置无效，因为线程池控制不跨进程继承。立即学习“Python免费学习笔记（深入）”；
方案二：预设环境变量（备选 ⚠️）
适用于无法修改子进程代码的场景，但有局限性：需在子进程导入 NumPy 前 设置，且对所有后续 NumPy 调用全局生效。
import os # 在创建 Pool 前设置（影响所有子进程） os.environ["OMP_NUM_THREADS"] = "1" os.environ["OPENBLAS_NUM_THREADS"] = "1" os.environ["MKL_NUM_THREADS"] = "1" os.environ["VECLIB_MAXIMUM_THREADS"] = "1" # macOS Accelerate os.environ["NUMEXPR_NUM_THREADS"] = "1" # ⚠️ 必须在此之后导入 numpy！否则环境变量无效 import numpy as np import numpy.linalg as la
❗ 风险提示：此方式依赖库加载顺序，若子进程中存在其他提前导入 NumPy 的模块（如某些第三方库），可能导致设置失效；且无法实现“部分计算启用多线程”的细粒度控制。
最佳实践总结
-
永远监控系统负载：运行时执行
watch -n 1 'uptime'或htop，若load average显著高于物理核心数（如 32 核机器显示 load > 40），即存在线程过载； -
优先选用
threadpool_limits：精准、安全、可嵌套、易调试； -
避免混合并行范式：除非明确需要（如外层进程处理 I/O，内层线程处理计算），否则应统一使用进程级并行（
multiprocessing）或线程级并行（concurrent.futures.ThreadPoolExecutor+ GIL 友好操作）； - macOS 表现不同是正常现象：其 Accelerate 框架默认线程数通常更保守，而 Linux 服务器上的 OpenBLAS/MKL 往往默认启用全部核心，故问题更显著。
遵循上述方法后，你的 4 进程并行任务将稳定在约 3–4 秒/任务（接近线性加速），彻底解决“加 CPU 反而变慢”的反直觉问题。
