内存溢出不是代码错误，而是资源超限；jupyter不自动释放内存，pytorch显存缓存、pandas全量加载、大文件读取等场景易引发oom，需分块处理、及时清理引用并监控内存指标。
内存溢出不是“代码写错了”，而是资源使用超出了当前内核或系统能承受的边界。Jupyter 本身不自动释放内存，加上 Python 的引用计数和垃圾回收机制在交互式环境中容易滞后，问题会集中爆发在 DataFrame 加载、PyTorch 训练、大文件读取等场景。
为什么 pd.read_csv() 一执行就报 MemoryError
因为默认行为是把整个文件一次性加载进内存。哪怕只是 2GB 的 CSV，read_csv() 也会尝试分配连续内存块，而你的内核可能只剩 1.5GB 可用空间。
- 用
chunksize参数分块读取：每次只加载一部分，处理完立刻丢弃引用 - 避免写
df = pd.read_csv('big.csv')后直接做df.groupby(...).apply(...)—— 这会让中间结果全留在内存里 - 读取时指定列（
usecols）和数据类型（dtype），比如把int64换成int32或category，可省下 30%~70% 内存
PyTorch 在 Jupyter 里跑几轮就 Kernel died
显存没释放，不是内存没释放。CUDA 缓存分配器会把显存“预留”着供下次复用，但不会还给系统。你看到 torch.cuda.memory_reserved() 持续上涨，就是它在悄悄囤货。
- 训练循环里必须加
optimizer.zero_grad()和loss.backward()后的del loss, output—— 不然计算图一直被引用 - 别把带
requires_grad=True的张量塞进列表：losses.append(loss)是高危操作；改用losses.append(loss.item()) - 手动清缓存：
torch.cuda.empty_cache()可以强制释放未被引用的显存，但不能解决根本泄漏
运行完代码，内存还是占着不放
Jupyter 内核默认保持活跃状态，所有变量、对象、导入模块都留在内存里，这是设计使然，不是 bug。你关掉浏览器标签页，内核还在后台跑着。
- 点击菜单栏 Kernel → Restart & Clear Output，比单纯
Restart更彻底 - 命令行里查内核进程：
jupyter kernel list，再用kill -9 PID强制终止残留内核（尤其当你改过内核配置后） - 长期运行任务建议改用脚本 +
python train.py，而不是在 Notebook 里反复Shift+Enter
服务器级内存不足导致 Internal Server Error
这不是 Notebook 本身的问题，是 Jupyter Server 进程被系统 OOM Killer 杀掉了。常见于云服务器上多个用户共用一台机器，或你开了太多内核没关。
- 检查配置文件
~/.jupyter/jupyter_server_config.py，设c.ServerApp.max_kernels = 3防止失控创建 - 启动时限制总内存：
jupyter notebook --ServerApp.memory_limit=6g，让内核在超限时主动退出，而非被强杀 - 配合
free -h和ps aux --sort=-%mem | head -10定期看谁在偷偷吃内存，特别是python或node进程
最常被忽略的一点：内存问题往往不是单点故障，而是多个小泄漏叠加的结果——一个没删的 DataFrame、一次没 .item() 的 loss、一个 chunk 读取后忘了 del chunk，三者加起来就能压垮内核。盯住 torch.cuda.memory_allocated() 和 gc.get_count()，比等崩溃后再排查更高效。
