NumPy数组在Jupyter中不释放内存的主因是IPython内核隐式持有引用，尤其是_和Out字典持续保留输出对象；需组合del变量、清空_、%reset、gc.collect及设arr=None等操作强制回收。
为什么NumPy数组在Jupyter里不释放内存？
不是NumPy本身“不释放”，而是Jupyter内核的变量生命周期管理方式导致对象残留。你在Notebook单元中创建的np.array（尤其是大数组）一旦被赋值给变量，就会被内核持久持有；即使你后续执行del arr或覆盖变量，只要该对象仍被其他变量、闭包、全局缓存或IPython历史记录隐式引用，它就无法被回收。
确认是否真由NumPy对象引发泄漏
别急着删代码——先验证问题源头。用psutil.Process().memory_info().rss在关键节点打点，比看任务管理器更准：
- 运行前记一次内存：
import psutil; start_mem = psutil.Process().memory_info().rss - 创建一个大数组：
arr = np.random.rand(10000, 10000) - 执行
del arr后立即再查：psutil.Process().memory_info().rss - start_mem - 如果差值仍达几百MB，说明对象没真正释放——这时再用
objgraph.show_growth(limit=5)查新增最多的类，大概率看到numpy.ndarray持续增长
强制清理NumPy对象的实操步骤
单纯del常失效，因为IPython会把上一个输出结果存进_，而大数组极易成为“上次输出”。必须组合操作：
- 显式清空所有可能持有引用的变量：
del arr; del _; del __; del ___ - 清空IPython历史缓存：
%reset -f（注意：这会清除所有用户定义变量，慎用） - 调用
gc.collect()前先禁用自动回收：gc.disable(); gc.collect(); gc.enable()——避免分代策略干扰强制回收 - 对已知占用大的数组，直接设为
None而非del：arr = None，更可靠切断强引用链
Jupyter容器级防护：防崩比救崩更重要
本地调试时内存泄漏还能手动干预，但生产环境的Jupyter容器一旦OOM，内核直接kill，连日志都来不及写。必须提前设限：
立即学习“Python免费学习笔记（深入）”；
- 启动容器时硬限制内存：
docker run --memory=3g --memory-swap=3g jupyter/datascience-notebook - 在
jupyter_server_config.py里加：c.ServerApp.shutdown_no_activity_timeout = 600（10分钟无活动自动关服务） - 禁用自动保存大输出：
c.NotebookApp.iopub_data_rate_limit = 1000000（单位字节/秒），防止plt.show()或df.head()把整张图/表塞进前端内存 - 读取大文件时永远分块：
pd.read_csv(..., chunksize=10000)+np.concatenate([chunk.values for chunk in reader])，别让全量ndarray一次性加载
最易被忽略的是IPython的_和Out字典——它们默认永久保留所有输出对象。哪怕你写了del arr，只要之前打印过arr.shape，那个数组就还挂在Out[5]里。这点在交互式环境中几乎无人检查，却是Jupyter场景下NumPy泄漏的头号推手。
