DataLoader卡住或吞吐低是因为cProfile无法监控num_workers>0时的子进程耗时；需设num_workers=0定位主进程瓶颈，再通过环境变量+__getitem__内cProfile分别采集worker性能数据。
为什么 DataLoader 启动后卡住或吞吐极低，cProfile 却没用？
因为默认的 DataLoader 开了多进程（num_workers > 0），而 cProfile 只能 profile 主进程——子进程里的耗时完全看不到。你看到的“慢”，大概率发生在 worker 进程里，比如图像解码、磁盘 I/O、自定义 __getitem__ 中的同步阻塞操作。
实操建议：
- 先设
num_workers=0测试单进程路径，用cProfile确认主流程瓶颈（如 transform 是否用了 PIL 的慢操作、是否在__getitem__里调了time.sleep或未缓存的文件读取） - 若单进程快、多进程慢，问题一定出在 worker 初始化或数据加载环节，此时
cProfile失效，需换方法 - 注意 Windows 下
spawn启动方式会导致每个 worker 重复导入模块、重建对象，可能触发意外初始化（如重复加载大模型、重复连接数据库）
怎样让 cProfile 覆盖所有 DataLoader worker 进程？
不能靠主进程启动 cProfile，得让每个 worker 自己 profile 并输出独立结果。最直接的方式是在 Dataset.__getitem__ 入口手动加 profile，但更稳妥的是 patch torch.utils.data._utils.worker._worker_loop ——不过这有版本风险。推荐轻量级方案：
在 Dataset.__getitem__ 开头插入：
立即学习“Python免费学习笔记（深入）”；
import cProfile
import os
if os.environ.get('PROFILE_WORKER') == '1':
pr = cProfile.Profile()
pr.enable()
然后启动前设置环境变量：os.environ['PROFILE_WORKER'] = '1'，并在 __getitem__ 结尾加 pr.dump_stats(f'worker_{os.getpid()}.prof')。这样每个 worker 输出一个 .prof 文件，用 snakeviz 分别查看即可。
让 macOS 自动化像说话一样简单 —— 用代码控制你的 Mac，无需学习 AppleScript 系统要求 macOS 14+ (Sonoma) Python 3.9+ 需要开启：辅助功能 + 屏幕录制权限
常见踩坑点：
- 不要在
__init__里做耗时操作（如遍历整个目录生成 file list），它会在主进程执行且被每个 worker 重复执行（fork模式下虽共享内存，但spawn下会重新运行） - 避免在
__getitem__中打开/关闭文件句柄——频繁系统调用会击穿磁盘 I/O；改用mmap或提前open并缓存句柄（注意进程间文件描述符不共享，需用torch.multiprocessing的Queue或Manager协调）
num_workers 设多少才合理？为什么设高了反而更慢？
不是越多越好。真实瓶颈常在磁盘带宽、内存带宽或 Python GIL（尤其 transform 里有大量 PIL/Numpy 计算时）。典型现象是 htop 显示 CPU 利用率不高但 iostat -x 1 显示 %util 接近 100%，说明卡在磁盘。
调试步骤：
- 从
num_workers=0开始，测 baseline 吞吐（记作 T₀） - 逐步增加到 2、4、8，同时用
nvidia-smi看 GPU 利用率是否提升；若 GPU 利用率没涨，说明数据供给没跟上，瓶颈不在 GPU 计算侧 - 超过某个值（如 8）后吞吐下降，大概率是 worker 间争抢磁盘或内存带宽，或触发 OS page cache 压力（尤其小文件多的 dataset）
- Linux 下可临时用
ionice -c 2 -n 0 python train.py降低 I/O 优先级，观察是否缓解卡顿——若缓解，说明 I/O 是瓶颈
哪些 transform 操作会让多进程 DataLoader 暗地变慢？
PIL 图像操作默认不开多线程，但某些 transform 会意外触发全局锁或隐式同步：
-
transforms.Resize+interpolation=PIL.Image.LANCZOS：Lanczos 插值在 PIL 内部是单线程实现，多个 worker 会排队等同一把锁 -
transforms.ColorJitter在旧版 Pillow（ - 自己写的
lambda x: x.numpy().astype(np.float32)：如果x是 CUDA tensor，会触发同步（.cpu() 隐式等待 kernel 完成） - 使用
cv2.imread但没关 OpenCV 多线程：cv2.setNumThreads(0)必须在每个 worker 里调用，否则多个 worker 里的 OpenCV 线程池互相抢资源
真正有效的加速手段，往往不是加 worker 数，而是把耗时操作移出 __getitem__：预解码图像存为 LMDB / Memory-mapped numpy array，或用 torchvision.io.read_image 替代 PIL（后者在 2023 年后已大幅优化 I/O 路径）。
最容易被忽略的一点：DataLoader 的 pin_memory=True 在非 CUDA 场景下不仅无用，还会增加内存拷贝开销；而 prefetch_factor 设得过大（如 > 4）在小 batch 场景下反而导致 worker 预取过多、挤占系统内存，引发 swap。
