scikit-learn 默认 n_jobs=-1 在 flask 等多线程 web 服务中极易引发资源争用与死锁，应显式设 backend="threading"、timeout=30、n_jobs=1 并禁用 openmp 和 joblib 缓存。
Scikit-learn 默认启用多线程（n_jobs=-1）时，极易与 Flask、APScheduler 或其他 Python 线程环境发生资源争用，导致进程卡死、响应停滞——这不是模型训练慢，而是线程调度被阻塞或锁死。
为什么 n_jobs=-1 在 Web 服务中特别危险
Scikit-learn 的并行后端（如 joblib）在 n_jobs=-1 下会 fork 出与 CPU 核心数相等的子进程/线程。但这些子进程仍共享主线程的 GIL 和资源句柄（如数据库连接、文件锁），尤其当主程序本身已在多线程运行（如 Flask 的多线程模式或 APScheduler 的后台线程）时：
- 子进程可能尝试重复获取已被主线程持有的锁（比如日志文件锁、临时目录锁）
- joblib 的进程池会竞争同一组系统资源（内存 + CPU），触发 OOM Killer 或频繁 swap
- 某些模型（如
RandomForestClassifier）内部调用 OpenMP，而 OpenMP 与 Python threading 混用时存在已知兼容性问题
joblib.Parallel 的 timeout 和 backend 控制
不要依赖全局 n_jobs，而是显式控制并行行为：
- 改用
backend="threading"替代默认的"loky"：避免 fork 开销和进程间锁冲突，适合 I/O 密集型或轻量计算 - 必须设
timeout=30（单位秒）：防止某个子任务卡住整个 Parallel 流程 - 禁用自动 joblib 缓存：
cache_location=None，避免磁盘 I/O 成为瓶颈（Prophet 和部分 sklearn transformer 会写缓存） - 示例：
from joblib import Parallel, delayed Parallel(n_jobs=2, backend="threading", timeout=30)( delayed(my_fit_func)(X_chunk, y_chunk) for X_chunk, y_chunk in chunks )
避免 FeatureUnion / Pipeline 中隐式并行引发死锁
FeatureUnion 和 Pipeline 的 n_jobs 参数是“传染性”的——只要其中任一 transformer 启用了并行（如 StandardScaler 不会，但自定义的 RFE 可能会），整个流程就可能陷入多层嵌套并行，加剧锁竞争：
- 显式关闭所有 transformer 的并行：
RFE(estimator, n_jobs=1)、PCA(n_components=10, svd_solver="arpack", n_jobs=1) - 禁用
FeatureUnion自身并行：FeatureUnion(transformer_list, n_jobs=1) - 若必须用并行特征工程，改用
ColumnTransformer+ 单线程 transformer 组合，它不触发 joblib 并行调度
关键收尾提醒
最易被忽略的是：Scikit-learn 的并行行为不仅受你代码控制，还受环境变量影响。务必检查并覆盖以下两项：
-
export OMP_NUM_THREADS=1（防止底层 OpenMP 多线程干扰） -
export JOBLIB_TEMP_FOLDER=/tmp/joblib_$$（避免多个请求共用同一缓存目录导致文件锁冲突）
这些不是“优化项”，而是在线服务中启用任何 sklearn 并行能力前的强制前置动作。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
