Python对象内存与引用计数解析

各位小伙伴们，大家好呀！看看今天我又给各位带来了什么文章？本文标题是《Python对象内存与引用计数详解》，很明显是关于文章的文章哈哈哈，其中内容主要会涉及到等等，如果能帮到你，觉得很不错的话，欢迎各位多多点评和分享！

id() 和 is 比较对象在内存中的实际地址，即 PyObject* 指针值；引用计数增减由底层指针操作触发，循环引用需 gc 模块清理；sys.getrefcount() 结果恒比真实值多 1。

Python 的 id() 和 is 到底在比较什么

它们比较的是对象在内存中的实际地址，也就是 CPython 解释器中 PyObject* 指针的值。不是“值相等”，也不是“类型一致”，纯粹是同一块内存区域的标识。

常见误用：用 is 判断数字或字符串是否“内容相同”。比如 1000 is 10**3 在某些 Python 版本返回 False，因为小整数（-5 到 256）会被缓存复用，但超出范围后每次字面量都会新建对象。

• 永远用 == 判断值是否相等，is 只用于确认是否为同一对象（如 obj is None）
• id() 返回的整数在对象生命周期内不变，但不同对象可能在不同时刻有相同 id()（内存复用）
• 多线程下 id() 不保证全局唯一，只在单次运行中对存活对象有效

引用计数怎么被触发增减

CPython 用引用计数作为主要内存管理机制，每个对象头里存着一个 ob_refcnt 计数器。它不是“变量引用次数”，而是“指向该对象的指针数量”。

增减发生在底层操作层面，比如：

• 赋值语句：a = obj → obj 引用计数 +1；a = b → 原 a 所指对象 -1，b 所指对象 +1
• 容器插入：lst.append(obj) → obj 计数 +1；lst.pop() → 对应对象 -1
• 函数传参：调用时形参获得实参对象的新引用，函数返回后局部变量销毁 → 计数 -1
• 循环引用不会自动触发减计数，这是引用计数模型的根本缺陷，必须靠 gc 模块的周期性扫描来清理

为什么 sys.getrefcount() 总比预期多 1

因为调用 sys.getrefcount(x) 这个动作本身，会让 x 临时多一个引用 —— 参数传递过程会增加一次计数。

例如：

import sys
a = []
print(sys.getrefcount(a))  # 输出通常是 2（不是 1）

这个“+1”是确定的、可预测的干扰项，不是 bug，也不是内存泄漏迹象。

• 不要用 getrefcount() 来调试循环引用，它掩盖了真实引用关系
• 想看对象被哪些地方持有时，用 gc.get_referrers(obj) 更直接（但注意它也可能引入临时引用）
• 在 C 扩展中手动调用 Py_INCREF/Py_DECREF 时，必须严格配对，否则计数错位会导致提前释放或内存泄漏

对象销毁时机与 __del__ 的不可靠性

当引用计数降到 0，CPython 立即调用对象的 __del__ 方法并释放内存。但这个“立即”仅限于当前线程、无异常、无循环引用的干净场景。

• __del__ 不保证执行顺序，多个对象互相引用时，谁先销毁无法预判
• 若 __del__ 抛出异常，解释器只会打印警告，不会中断程序，也不会重试
• 模块卸载阶段（解释器退出时），全局变量和模块级对象的引用计数归零顺序不确定，__del__ 可能访问已销毁的其他对象
• 真正需要资源清理时，优先用 with 语句或显式 .close()，而不是依赖 __del__

引用计数的简洁性是以牺牲确定性和跨实现兼容性换来的。一旦涉及多线程、C 扩展或长期运行的服务，就得直面它的边界 —— 那些没被 gc 捕获的循环、那些在解释器关闭时静默消失的 __del__、还有那些你以为“应该被释放”却还挂在某个闭包里的对象。

以上就是《Python对象内存与引用计数解析》的详细内容，更多关于的资料请关注golang学习网公众号！