设置n_jobs有时不提速甚至更慢，因算法本身不支持（如LogisticRegression的lbfgs求解器）、小数据下通信开销超收益、GridSearchCV与内层estimator双重并行导致OOM、Windows下spawn机制引发递归错误，以及pickle序列化大数组耗时。
为什么设置 n_jobs 有时没提速甚至更慢
不是所有 Scikit-learn 算法都支持并行，也不是所有数据规模下多核都有收益。比如 LogisticRegression 默认用 solver='lbfgs' 时完全不走 n_jobs；而 RandomForestClassifier 的 n_jobs 控制的是树之间的并行，但每棵树内部仍是单线程。小数据（
实操建议：
立即学习“Python免费学习笔记（深入）”；
- 优先查文档确认算法是否支持
n_jobs—— 比如GridSearchCV、RandomForest*、Bagging*、KMeans支持；SVM（sklearn.svm.SVC）不支持 - 用
time.time()对比训练耗时，别只看 CPU 使用率 - 避免设成远超物理核心数的值（如
n_jobs=32在 8 核机器上），容易引发上下文切换抖动
n_jobs=-1 到底用了几个核心
n_jobs=-1 表示“用满所有逻辑核心”，不是物理核心。在超线程开启的 CPU 上（如 8 核 16 线程），它会起 16 个 worker 进程/线程。但多数 scikit-learn 并行基于 joblib 的多进程（loky 后端），进程间通信和内存拷贝成本高，尤其当训练数据大时，可能因频繁序列化导致卡顿。
实操建议：
立即学习“Python免费学习笔记（深入）”；
- 对内存敏感场景（如 >2GB 数据），先试
n_jobs=2或n_jobs=4，再逐步加 - 显式指定后端可微调：比如
parallel_backend('threading')适合轻量计算 + 共享内存，但要注意 GIL 限制 - 用
os.cpu_count()查清机器真实逻辑核心数，心里有底
GridSearchCV 中的 n_jobs 有两层含义
GridSearchCV 自身有 n_jobs 参数，控制参数组合的并行；而它包裹的 estimator（如 RandomForestClassifier）也可能有自己的 n_jobs。两者叠加时，总并发数是乘积关系 —— 容易把系统跑满、触发 OOM 或 swap。
实操建议：
立即学习“Python免费学习笔记（深入）”；
- 外层
GridSearchCV(n_jobs=4)+ 内层RandomForestClassifier(n_jobs=1)是更稳的搭配 - 如果内层 estimator 本身就很重（如大树、大数据），干脆关掉它的
n_jobs（设为1），只让 CV 折数并行 - 错误现象示例：
OSError: [Errno 12] Cannot allocate memory很可能就是双重并行撑爆内存
Windows 下多进程并行失败的典型报错和绕过方式
Windows 缺乏 fork 支持，joblib 默认用 spawn 启动子进程，若主脚本没加 if __name__ == '__main__': 保护，会反复导入模块、递归创建进程，最终报 RecursionError 或直接卡死。
实操建议：
立即学习“Python免费学习笔记（深入）”；
- 必须确保训练代码包裹在
if __name__ == '__main__':块里 - 临时调试时可改用
parallel_backend('threading')，但注意线程仍受 GIL 影响，CPU 密集型任务提速有限 - 错误信息典型长这样：
RuntimeError: An attempt has been made to start a new process before the current process has finished its bootstrapping phase.
memmap 或 shared_memory 手动共享数据。 
