为何Jupyter资源使用量与sys.getsizeof结果差异巨大？

核心原因是两者统计的内存范围完全不同，具体拆解如下：

1. sys.getsizeof只统计对象本身的直接大小，不包含内部元素的占用 #

sys.getsizeof(foo)返回的只是列表这个容器结构的内存大小——在64位系统中，列表里每个元素是一个指针（8字节），1亿个指针就是100_000_000 * 8 = 800MB，再加上列表本身的元数据开销（比如长度、容量等），所以总共有约850MB，这完全符合你看到的结果。

但列表里的1亿个整数对象（n）的内存占用，sys.getsizeof根本没算进去！在CPython中，每个整数都是一个PyLongObject对象，只要超出了内置的小整数缓存范围（-5到256），都会占用额外的内存空间。以64位系统为例，每个普通整数对象大概占用28字节，1亿个这样的对象就要占100_000_000 * 28 = 2800MB（约2.7GB），加上列表本身的850MB，这就已经接近3.5GB了，和jupyter显示的3.75GB差不了多少。

2. jupyter_resource_usage统计的是整个Python进程的物理内存占用 #

jupyter_resource_usage显示的是整个Jupyter内核进程的RSS（常驻集大小），它包含了：

• 所有Python对象（包括列表和里面的整数）的内存
• Python解释器本身的运行内存
• 已加载的模块、临时变量、内存分配器预留的空闲内存
• 内存碎片（Python内存分配器为了减少分配开销，会预留一些内存空间，这些也会被算进进程内存）

这就是为什么它的数值远大于sys.getsizeof的结果——它统计的是进程整体的内存消耗，而不是单个对象的直接大小。

关于状态栏内存变化的补充 #

你提到运行代码后状态栏先显示1.28GB，几秒后升到3.96GB，这是因为列表生成器是逐步创建元素的，Python会随着元素添加逐步分配内存；另外，内存分配器可能会延迟向操作系统申请内存，或者有缓存机制，导致进程内存的统计有一定滞后性。而执行del foo后内存回到初始值，是因为foo被删除后，列表和里面的整数对象的引用计数归零，CPython的垃圾回收器会释放这些内存，进程内存也就降下来了。

内容的提问来源于stack exchange，提问作者Stalpotaten