Python深度学习加载数据技巧_DataLoader批量处理与数据增强-Python教程-PHP中文网

PyTorch DataLoader卡在__iter__主因是Linux下fork子进程继承损坏CUDA状态，应改用spawn启动；或共享内存不足，可设pin_memory=False或升级PyTorch。

python深度学习加载数据技巧_dataloader批量处理与数据增强

PyTorch DataLoader卡在 iter 但没报错？检查 num_workers 和共享内存

常见现象是训练启动后卡住几秒甚至几十秒，DataLoader 不吐数据，GPU 闲置，nvidia-smi 显示显存已占但 train_step 没跑。本质是子进程初始化阻塞，尤其在 Linux + 多 num_workers > 0 时高频发生。

num_workers=0 时一切正常 → 基本锁定是子进程问题，不是数据路径或 transform 错误
Linux 下默认用 fork 启动子进程，若主进程已加载 CUDA 上下文（比如提前调用了 torch.cuda.is_available()），子进程会继承损坏的 CUDA 状态 → 改用 spawn 启动方式：torch.multiprocessing.set_start_method("spawn", force=True)（必须放在 if __name__ == "__main__": 下且早于任何 CUDA 调用）
Windows/macOS 用户更常遇到 SharedMemory 不足：DataLoader 默认用共享内存传 tensor，大数据集 + 高 batch_size 容易撑爆 → 加 pin_memory=False 或升级 PyTorch（1.12+ 对共享内存管理更稳）
调试技巧：临时设 num_workers=0 看是否跑通；再逐步加到 1、2，观察卡点；配合 torch.utils.data.get_worker_info() 在 Dataset.__getitem__ 里打日志定位具体哪条样本卡住

RandomHorizontalFlip 为什么没生效？transform 顺序和 PIL/Tensor 类型不匹配

写了 RandomHorizontalFlip(p=1.0) 却发现图像从不翻转，或者翻转后变黑/错位——大概率是输入类型不对，或和其他 transform 冲突了。

RandomHorizontalFlip 只接受 PIL.Image 或 torch.Tensor（CHW 格式），如果你在 ToTensor() 之前就调用它，会直接抛 TypeError: img should be PIL Image；反过来，如果在 ToTensor() 之后调用，它也能处理 tensor，但必须确保 tensor 是 float32 且值域在 [0,1]（ToTensor() 默认归一化到此范围）
别把 RandomHorizontalFlip 和 RandomRotation 这类空间变换放在 Normalize() 之后 —— Normalize 依赖固定均值方差，翻转本身不影响统计量，但若你自定义了 per-image normalize 就可能出问题
验证是否生效：在 Dataset.__getitem__ 返回前加 print(sample_tensor[0, :3, :3])（取左上角像素），连续看两个 batch，翻转后第一行像素应变成最后一行

自定义 Dataset 的 getitem 里做 heavy IO 怎么提速？缓存 + prefetch + lazy load 组合用

读 HDF5/大 TIFF/远程 S3 文件时，单次 __getitem__ 耗时 >100ms，DataLoader 再多 worker 也救不了吞吐 —— 瓶颈不在 CPU/GPU，而在磁盘或网络延迟。

macOS UI 自动化技能包 —— 用 Python 控制你的 Mac

让 macOS 自动化像说话一样简单 —— 用代码控制你的 Mac，无需学习 AppleScript 系统要求 macOS 14+ (Sonoma) Python 3.9+ 需要开启：辅助功能 + 屏幕录制权限

下载

优先用内存映射：HDF5 用 h5py.File(..., swmr=True) + ds = f["data"][idx]（不 load 全量）；TIFF 用 tifffile.memmap()
小文件（self.data = [np.load(p) for p in self.paths]，但注意 OOM 风险，可用 psutil.virtual_memory().available 估算余量
远程数据（S3/HTTP）务必加缓存层：torch.hub.load_state_dict_from_url(..., cache_dir="./s3_cache") 或自己用 diskcache 库按 hash 缓存响应体
避免在 __getitem__ 里重复打开/关闭文件句柄 —— 把 open() 提到 __init__，复用 file object（注意线程/进程安全，num_workers>0 时每个 worker 有独立副本）

collate_fn 写错导致 RuntimeError: stack expects each tensor to be equal size？

当 batch 中图像尺寸不一致（比如检测任务中不同分辨率的图，或 padding 前的 mask），default_collate 会直接报 stack 失败 —— 它不做 resize/pad，只尝试 torch.stack()。

最简解法：写一个 collate_fn 对 list[torch.Tensor] 做统一 resize（F.interpolate）或 pad（F.pad），但注意不要在 collate 里调 .cuda() —— 设备转移应留给模型 forward 前做
检测/分割任务推荐用 torchvision.ops.misc.nested_tensor_from_tensor_list（PyTorch 1.10+），它保留各 tensor 原始 shape，返回 NestedTensor，后续可被专用算子消费
别在 collate_fn 里做 augmentation —— 那属于 per-sample 行为，放 Dataset.__getitem__ 更合理；collate 只该干“对齐”和“合并”两件事
debug 技巧：在 collate_fn 开头加 print([x.shape for x in batch])，一眼看出哪些维度不一致（H/W 不同？channel 数不一？）

真正难调的永远不是单个 API 怎么用，而是多个机制叠加后的隐式耦合：比如 num_workers 触发的 fork/spawn 差异、pin_memory 和 GPU 显存分配策略的交互、甚至 Linux cgroups 限制了子进程能用的内存上限。这些地方没报错，但慢得离谱，得靠 strace -p $(pgrep -f "python train.py") 或 torch.utils.bottleneck 才挖得出来。