n_jobs未加速甚至变慢主因是轻量任务下进程开销超计算收益；仅cpu密集型、单次≥100ms任务才适合并行；其值含义：1为串行，正整数指定进程数，-1用满逻辑核心，-2留一核，0非法。
为什么 n_jobs 有时没加速，甚至变慢？
直接设 n_jobs=-1 并不总能提速，尤其当任务本身很轻（比如几毫秒内完成）或数据量小的时候。进程启动、序列化参数、IPC通信的开销可能远超计算收益。典型表现是：单进程耗时 10ms，设 n_jobs=4 后反而要 30ms。
- 只对 CPU 密集型、单次耗时 ≥ 100ms 的任务才值得并行
-
n_jobs是 scikit-learn 等库的参数，不是 Python 内置语法——它背后调用的是joblib.Parallel，不是原生multiprocessing - 若函数含不可序列化对象（如嵌套 lambda、未导入模块的类实例），会报
PicklingError
n_jobs 可取哪些值？含义和陷阱是什么？
n_jobs 控制并发 worker 数量，但语义因库而异。在 scikit-learn 中：
-
n_jobs=1：强制串行，忽略并行逻辑（调试时有用） -
n_jobs=2或正整数：启动指定数量的进程 -
n_jobs=-1：用满所有逻辑 CPU 核心（注意：不是物理核心数，os.cpu_count()返回的值） -
n_jobs=-2：留一个核心给系统或其他任务（适合桌面环境后台跑训练）
⚠️ 坑：n_jobs=0 不是“自动选择”，而是抛出 ValueError；某些旧版 joblib 对负值处理不一致，建议显式用 -1 或 os.cpu_count() - 1。
如何确认并行真的在跑？
光看运行时间不够，得验证是否真起了多个进程。最简单方法是加日志：
import logging logging.basicConfig(level=logging.INFO) # 然后调用如 GridSearchCV(..., n_jobs=2)
你会看到类似 INFO:joblib.Parallel:Using backend LokyBackend with 2 concurrent workers. 的输出。也可用系统命令观察：htop（Linux/macOS）或任务管理器（Windows）中找多个 python 进程。
安全 Python 代码沙箱：在隔离的沙箱中执行任意 Python 代码，预装 requests、NumPy、pandas 库。返回 stdout、stderr。
- 若只看到 1 个 python 进程，检查是否误用了
n_jobs不支持的方法（如某些自定义 estimator 未继承BaseEstimator） - Windows 下需确保代码入口有
if __name__ == '__main__':保护，否则子进程反复导入主模块导致死循环
想精细控制并行，该换 joblib.Parallel 还是 multiprocessing？
直接用 joblib.Parallel 更省事，尤其和 sklearn 生态配合时。它默认用 LokyBackend（比老版 threading 更安全，支持进程间内存共享）。
示例：
from joblib import Parallel, delayed
def square(x):
return x ** 2
results = Parallel(n_jobs=2)(delayed(square)(i) for i in range(10))
但如果你需要：跨进程共享状态（如累计进度）、细粒度错误捕获、或调用 C 扩展（可能不兼容 joblib 的 pickle 机制），就得上原生 multiprocessing，此时 n_jobs 失效，要自己建 Pool。
真正容易被忽略的是内存：每个进程会复制一份全局数据（如大数组），n_jobs=4 可能吃掉 4 倍内存。用 joblib.Memory 缓存中间结果或改用 sharedmem 才能缓解。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
