根本原因是子进程启动时复用父进程的cuda上下文或opencv等非fork-safe库的全局状态，导致初始化阻塞；典型表现为卡在for batch in dataloader:且无报错。
为什么设置 num_workers > 0 时 DataLoader 会卡死？
根本原因不是 PyTorch 本身出错，而是子进程在启动时尝试复用父进程的 CUDA 上下文或某些全局状态（比如 OpenMP、OpenCV、logging 配置），导致初始化阻塞。最典型的现象是：程序停在 DataLoader 迭代第一轮，for batch in dataloader: 不往下走，CPU 占用低，GPU 显存无变化，且无报错。
常见诱因包括：
- 主进程已调用
torch.cuda.is_available()或创建过 CUDA tensor - 使用了某些非 fork-safe 的库（如
cv2在 Windows/macOS 上默认用 spawn 启动，但部分版本未正确重置 OpenCV 线程池） - 自定义
Dataset.__getitem__中隐式触发了 logging、matplotlib、h5py 等不支持多进程初始化的模块
如何安全启用 num_workers > 0？关键三步
不用删掉多进程，只需切断子进程对父进程敏感状态的继承路径：
-
把所有 CUDA 初始化操作移到
DataLoader创建之后——比如不要在__init__.py或模块顶层写device = torch.device('cuda')，而是在训练循环里首次需要时再获取 -
显式指定
pin_memory=False（尤其在 CPU-only 环境或调试阶段），因为pin_memory=True会触发 CUDA 上下文预分配，加剧 fork 冲突 -
在
if __name__ == '__main__':下启动训练脚本，并加上torch.multiprocessing.set_start_method('spawn')（仅需一次，放在主入口最上方）
示例片段：
if __name__ == '__main__':
torch.multiprocessing.set_start_method('spawn') # 必须在最前
train_loader = DataLoader(dataset, num_workers=4, pin_memory=False)
# 此后才做 model.to('cuda') 或 torch.cuda.empty_cache()
set_start_method 选 'fork' 还是 'spawn'？
Linux 下默认 'fork' 性能略好，但极容易因继承父进程 CUDA 状态而死锁；'spawn' 更干净，每个子进程从头导入模块、初始化环境，兼容性高，是多数场景的实际首选。
注意两点：
- Windows/macOS 强制使用
'spawn'，所以写跨平台代码时直接统一设为'spawn'反而省心 - 设成
'spawn'后，Dataset对象必须能被 pickle 序列化——避免在__init__中传入 lambda、open 的文件句柄、threading.Lock 等不可序列化对象
调试死锁时该看什么？
别只盯着 Python 日志，真实瓶颈常藏在系统级行为里：
- 运行
ps aux | grep python，观察 worker 进程是否处于T（stopped）或长时间S（sleeping）状态 - 用
strace -p <worker_pid></worker_pid>（Linux）抓系统调用，如果卡在sem_wait或futex，基本确认是线程/信号量资源未重置 - 临时把
num_workers=0运行通，再逐个打开__getitem__中的第三方调用（如cv2.imread→ 改用PIL.Image.open），定位具体冲突点
真正麻烦的不是改几行代码，而是有些库（比如旧版 librosa）会在 import 时悄悄启动线程池，这种必须在子进程中重新 import 才能规避——意味着你得把相关 import 全部挪进 __getitem__ 内部，而不是模块顶部。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
