VS Code中IPython的GC异常：变量实例化前ID已被追踪？

问题重现 #

在VS Code的IPython笔记本中，尝试用gc.get_objects()编写对象追踪工具时出现异常行为，简化示例如下：

第1单元格代码 #

import gc

__objs = gc.get_objects()
_objs = [id(o) for o in __objs]

#del __objs

第2单元格代码 #

variable = ["test"]

第3单元格代码 #

id(variable) in _objs

• 保留#del __objs注释时，第3单元格结果为预期的False；
• 取消del __objs注释后，第3单元格结果变为True；
• 但将所有代码放在同一单元格或.py文件中运行时，结果始终为False。

核心原因解析 #

这个现象是IPython单元格的变量生命周期特性和Python的内存ID复用机制共同作用的结果：

1. IPython单元格的变量留存规则
   IPython的每个单元格运行后，变量会默认保留在用户命名空间中。如果不删除__objs，这个列表会一直持有所有初始GC对象的引用，这些对象无法被垃圾回收，它们的内存地址（即对象ID）也就不会被释放重用。

2. 删除__objs后的内存回收与ID复用
   执行del __objs后，该列表的引用被清除，它本身会被标记为可回收；同时它持有的大量对象引用被释放，那些没有其他引用的对象会被GC回收，对应的内存地址会被放回Python的内存地址池。当第2单元格创建新列表["test"]时，Python会优先复用这些刚释放的旧地址，导致新对象的ID恰好出现在之前记录的_objs列表中。

3. 单单元格/普通.py文件的差异
   在单单元格或普通.py文件中，所有代码是连续执行的：从创建__objs到删除它，再到创建新对象的过程几乎瞬间完成。Python的GC是惰性触发的，不会在这段极短的时间内回收旧对象，因此新对象只能使用全新的内存地址，不会与_objs中的旧ID重叠。而IPython分单元格执行的模式，给了GC足够的时间在单元格间隙完成回收，甚至IPython本身会在间隙触发GC，加速了旧地址的复用。

总结 #

这个诡异现象本质是IPython分步执行的特性，让GC有机会在单元格间隙回收旧对象，导致后续新对象复用了旧ID；而单文件/单单元格的连续执行流程，没有给GC触发回收的时间，因此不会出现ID重叠的情况。

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