问题描述：

这是我的代码：

from memory_profiler import profile

@profile
def mess_with_memory():
    huge_list = range(20000000)
    del huge_list
    print "why this kolaveri di?"

当我从解释器运行它时，输出如下：

行号 内存使用量 增量 行内容

 3      7.0 MiB      0.0 MiB   @profile
 4                             def mess_with_memory():
 5                             
 6    628.5 MiB    621.5 MiB       huge_list = range(20000000)
 7    476.0 MiB   -152.6 MiB       del huge_list
 8    476.0 MiB      0.0 MiB       print "why this kolaveri di"

如果您注意到输出，创建大列表消耗了 621.5 MB，而删除它只释放了 152.6 MB。当我检查文档时，我发现了以下语句：

the statement del x removes the binding of x from the namespace referenced by the local scope

所以我猜想它并没有删除对象本身，而只是解除了绑定。但是，它在解除绑定时做了什么，以至于释放了这么多空间（152.6 MB）。有人能费心向我解释一下这里发生了什么吗？

解决方案 1：

Python 是一种垃圾收集语言。如果某个值不再“可从代码中获取”，则它最终将被删除。

如您所见，该del语句删除了变量的绑定。变量不是值，它们只是值的名称。

如果该变量是任何地方对该值的唯一引用，则该值最终将被删除。特别是在 CPython 中，垃圾收集器是建立在引用计数之上的。因此，“最终”意味着“立即”。*在其他实现中，通常是“很快”。

但是，如果有对同一值的其他引用，则仅删除其中一个引用（无论是通过del x、x = None退出存在的范围x等）都不能清理任何内容。**

这里还有一个问题。我不知道memory_profiler模块（大概是这个）实际上测量的是什么，但描述（谈论使用psutil）听起来像是从“外部”测量你的内存使用情况。

当 Python 释放存储空间时，它并不总是（甚至通常也不会）将其归还给操作系统。它会在多个级别保留“空闲列表”，以便能够比必须一路返回操作系统来请求更多内存更快地重新使用内存。在现代系统中，这很少会成为问题 — 如果您再次需要存储空间，那么拥有它就很好；如果您不需要，它会在其他人需要时立即被调出，并且永远不会被调回，因此几乎没有什么危害。

（除此之外，我上面所说的“操作系统”实际上是由多个级别组成的抽象，从malloc库到核心 C 库再到内核/分页器，并且这些级别中至少有一个通常有自己的空闲列表。）

如果你想从内部角度跟踪内存使用情况……嗯，这很难。由于新tracemalloc模块的存在，在 Python 3.4 中，这变得容易得多。有各种第三方模块（例如heapy/ guppy、Pympler、 ）试图获取与早期版本相同类型的信息，但这很困难，因为在PEP 445meliae之前，从各种分配器获取信息并将该信息与垃圾收集器绑定非常困难。

• 在某些情况下，存在对该值的引用……但仅来自本身无法访问的其他引用，可能处于循环中。就垃圾收集器而言，这仍算作“无法访问”，但就引用计数而言则不是。因此，CPython 还有一个“循环检测器”，它会不时运行，并找到相互可访问但其他任何人都无法访问的值的循环并清理它们。

如果您在交互式控制台中测试，则可能存在难以跟踪的隐藏值引用，因此您可能会认为已经摆脱了最后一个引用，但实际上并非如此。在脚本中，即使不容易，也应该始终能够弄清楚事情。模块可以提供帮助，调试器也可以。但当然，它们两者也为您提供了添加其他隐藏引用的新方法。gc

解决方案 2：

除了abarnert的优秀回答之外，我想添加一个python中循环引用的例子：

class RefCycleExample:
    def __init__(self):
        self.myself = self

    def __del__(self):
        print("deleting")

obj = RefCycleExample()
del obj

在上面的例子中，在 之后del obj，obj将是不可访问的；但是，由于本身具有指向自身的属性（引用循环），因此它不会立即被垃圾回收。相反，它会在未来的某个时间被垃圾回收，或者在 iterpreter 执行 时被垃圾回收gc.collect()。