Python对象池、内建属性与属性拦截器：内存管理与属性访问深度解析

有一次我在一个技术群里看到有人贴了一段代码，问为什么a = 257; b = 257; a is b在交互环境里返回False，而换成256就是True。群里瞬间炸出一堆答案，有人说这是小整数池，有人说这是intern机制，还有人说"你运气不好，对象被 GC 回收了"。其实这些回答都沾边，但没说到根上。这个话题牵扯出来的，正是 Python 内存管理里最常被聊、也最容易被搞混的三样东西：对象池（小整数池、大整数池/free list、intern 机制）、对象内建属性、以及属性拦截器。我把它们串在一起梳理了一遍，顺带附上这些年实际踩过的一些坑。

1. 从一道"送命题"说起：为什么 256 能共享、257 就不能

如果你刚接触 Python 不久，可能被is和==的区别搞晕过。简单说，==比较的是两个变量的值是否相等，is比较的是两个变量是否引用同一个对象，也就是内存地址是否相同。日常写代码我几乎只用==，因为业务逻辑关心的是"值对不对"，而不是"是不是同一块内存"。但面试或者读框架源码时，is却经常冒出来，尤其是在判断单例对象、枚举值、默认参数的时候。

小整数池就是导致上面那个"送命题"的元凶之一。CPython 在启动的过程中，会把-5到256之间的整数对象提前创建好，放在一个全局数组里。这个区间内，不管你用哪种方式拿到这些整数，比如字面量100、2**3、int("50")，最终拿到的都是同一个预先创建好的对象。所以：

>>> a = 256 >>> b = 256 >>> a is b True

而257不在这个预先创建的范围内，普通情况下每次计算都会创建一个新对象，所以a is b就是False。这里有一个非常经典的坑：为什么有人在自己的.py文件里写a, b = 257, 257，然后用a is b一测，发现是True？

原因是 CPython 编译代码块时，会把相同的常量折叠进同一个常量元组co_consts。也就是说，在同一个代码块里出现的两个257，编译器认为它们内容一样，直接复用了同一个常量对象。这段代码和交互环境逐行执行的路径不一样，所以结果相反。实战中我遇到过不止一次，有人因为这种表现差异，误以为"大整数也是缓存的"，然后在生产代码里用is比较整数，最后被线上数据狠狠教育了一顿。

所以关于小整数池，你只需要记住两个重点：第一，它是 CPython 实现的缓存机制，不是 Python 语言规范强制的；第二，它的范围通常是[-5, 256]，这个范围的选择有一定工程考量——256是一个字节能表示的最大值，索引、计数、编码转换里出现频率极高，而-5以下在常见循环边界里很少用到。这个池子里的对象会被全局持有引用，不会被垃圾回收，所以任何时候你拿到100，它都是同一个对象。

2. "大整数池"到底存不存在：free list 与常量缓存的真实关系

很多人听过大整数池这个词，但翻遍官方文档也找不到正儿八经的"大整数池"条目。这不是你资料找得不对，而是这本来就是一个民间叫法，背后其实是几层不同机制的混合效果。我也曾经被这个词带偏过，花了不少时间才理清楚，这里直接给你拆开讲。

第一层是编译期的常量缓存，也就是上面说的co_consts。这个缓存对任何数值都生效，不管多大，只要在同一个代码块里出现多次且值相同，编译器就可能复用同一个对象。但它有明显的局限性：离开当前代码块就不保证有效，进入函数内部、循环内部，行为都会变。

第二层是小整数池，硬编码只覆盖[-5, 256]。这一层范围明确、全局有效。

第三层才是重点，也是"大整数池"这个说法最接近的真相：内存块级别的 free list。在新一些的 CPython 实现里，整数对象被销毁时，如果 free list 还没满，这块内存块不会立刻归还给操作系统，而是被放进一个空闲列表里。下次再创建整数对象时，解释器会优先从空闲列表里取一块内存出来复用。这就像你租房退租后，中介把钥匙保管在手里，等下一个租客来了直接给钥匙，省去了重新找房源、重新签约的整套流程。

这个机制带来一个很有意思的现象：如果你连续创建、销毁同样的大整数，id()可能会重复出现。下面这段代码你在多数新版本 CPython 里跑，会看到前两次打印的地址相同：

def get_id(): a = 10**18 b = 10**18 return id(a), id(b) print(get_id()) print(get_id())

第一次调用时创建了两个10**18，它们可能在同一个代码块中被常量复用，所以id一样；函数返回后这两个对象引用计数归零，内存块进入 free list。第二次调用时，新对象又复用了之前释放的内存块，所以你看到的地址可能还是那一个。这很容易给人造成一种"大整数也被池化了"的错觉。

但你要清醒：free list 缓存的是内存块，不是数值。它不关心这块内存以后装的是10**18还是10**19，只要大小够用就能复用。因此你绝对不能依赖id()是否相同来判断两个大整数是否相等，也不该用is去比较任何整数。曾经有个同事为了"优化性能"，在字典取值后判断对象是否相同时用了is，结果在数据量大、对象频繁创建销毁的环境里出现了诡异的间歇性 bug，排查了很久才发现是 free list 让不同对象的内存地址偶尔重合。这种 bug 极其隐蔽，复现条件苛刻，代价非常高。

工程上，对整数比较只有一个安全姿势：用==。如果你想深挖 free list 的具体实现，可以直接去看 CPython 源码里int_free_list相关的逻辑，不同小版本的容量上限和触发条件略有差异，但这属于"知道就行"的奇技淫巧，不建议依赖它写业务代码。

3. intern 机制：字符串世界的"同一张身份证"

字符串驻留（intern）是另一个绕不开的缓存机制。它的核心思想很朴素：字符串是不可变对象，既然内容一样的字符串谁也不会修改它，那就不如让所有相同内容的字符串都指向同一个对象，既省内存又省比较时间。这个思路和整数对象池如出一辙，都是"用共享换效率"。

CPython 的字符串驻留分几个层次。第一层是标识符驻留，也就是变量名、函数名、类名、属性名这些源码里出现的"名字"，在编译阶段就会被驻留。它们几乎全部是合法的标识符形式，而 Python 源码里这些名字又会被反复引用，驻留的收益非常高。第二层是单字符字符串和空字符串，CPython 内部有一张针对 Latin-1 单字符的缓存表，所以像"a"、"1"这种单字符字符串，大部分情况下拿到的都是同一个对象。第三层是整数字符串，"0"到"256"这些由数字组成的字符串也会被缓存，用于和整数对象配合使用。

不过最容易被误解的是第四层：看起来像标识符的字符串字面量。在新一些的 CPython 版本中，源码里出现的字符串字面量，如果内容恰好满足标识符的字符组成规则（字母、数字、下划线，且不以数字开头），也有可能会被自动驻留。所以你会看到这样的现象：

>>> a = "hello_world" >>> b = "hello_world" >>> a is b True >>> c = "hello world" >>> d = "hello world" >>> c is d False

问题在于"有可能"这三个字。字符串驻留是否触发，和字符串长度、代码块的编译方式、版本实现都有关系。比如某些版本对非标识符字符串也可能做驻留优化，某些版本在交互环境下的行为又和文件里不一样。最坑的是，is的结果在不同小版本之间都可能变化，你完全不能拿它当逻辑判断用。

如果你确实需要确保两个字符串是同一个对象，办法是显式调用sys.intern()：

import sys key1 = sys.intern("some_long_business_key") key2 = sys.intern("some_long_business_key") print(key1 is key2) # True

这个操作会去一张全局驻留表里查，如果已经存在相同内容的字符串，就直接返回已有对象；否则把新的加进去。它最明显的收益体现在两个场景：一是大量重复字符串做==比较时，驻留后可以改成is比较，直接比指针，速度飞快；二是重复出现的字符串只保留一份内存，降低内存占用。我做过一次日志解析工具的重构，源数据里来自几十万个用户请求，包含大量重复的状态字段，把每个字段值都sys.intern()之后，内存占用从 800 多 MB 降到了 200 多 MB，解析时间也缩短了不少。

但同样要泼一盆冷水：sys.intern()的内存是常驻的，驻留表不会主动释放，如果你把大量的动态字符串（比如带随机数、时间戳的内容）也塞进去，内存反而会爆炸。这个工具适合"低基数、高重复"的数据，不适合"高基数、低重复"的数据，用之前一定要权衡清楚。

4. 内建属性：每个对象身上都带着的"固定行李"

说完了对象池，接下来聊内建属性。你随便创建一个 Python 对象，它身上除了你自己定义的属性之外，还有一大堆"出厂自带"的属性，比如__dict__、__class__、__doc__、__module__，这些统称为内建属性。它们不是某个类私有设计出来的，而是 Python 对象模型的一部分。

我整理了一张常见内建属性的表，方便你平时查阅：

这里我最想多说几句的是__dict__，因为它直接和内存管理挂钩。默认情况下，你创建一个类的两个实例，它们各自维护一个独立的属性字典__dict__。这个字典让实例属性可以动态添加、读取、修改，非常灵活，但灵活性是有代价的：每个实例都要多占一份字典对象的内存。典型的空字典大约占 64 字节左右，当一个程序里创建了几百万个小对象时，光是实例的__dict__就会积少成多。

如果你需要的是固定结构的对象，__slots__是一个值得研究的优化手段。在类里声明__slots__ = ("name", "age")之后，实例不再自动生成__dict__，属性被改为在底层用类似 C 结构体的方式存储。带来的直接效果是：单个实例的内存显著下降，同时属性访问速度也会快一点。代价是不能再随意添加未声明的属性。我的经验是，如果要做大规模数据建模，并且实例数量达到十万级以上，__slots__带来的收益是可以直接量出来的；如果只是百八十个对象，就不用折腾了，灵活性的价值更大。

内建属性还有一个容易忽略的点：类和实例的__dict__是两回事。类对象的__dict__是一个mappingproxy对象，里面装着类的方法、类变量、描述符；实例的__dict__才是存实例属性的普通字典。你用dir(obj)看到的一长串名字，其实是 Python 把类属性、实例属性和一部分内建属性合并排序后的结果，不要把它和__dict__混为一谈。调试属性冲突时，可以先分别打印obj.__dict__和type(obj).__dict__，看清楚属性到底落在哪一层，再决定怎么处理。

5. 属性拦截器：把属性的读写接管到自己手里

如果说内建属性是每个对象身上预装好的"硬件设施"，那属性拦截器就是你自定义的操作系统，可以劫持属性的读取和赋值流程。Python 提供了三个主要入口：__getattr__、__setattr__、__delattr__，以及一个更底层的__getattribute__。

先说最常用的__getattr__。它有一个精准的触发条件：只有在常规属性查找失败之后才会被调用。也就是说，实例自身属性找不到、类属性也找不到、描述符也没有匹配时，Python 才会把控制权交给你。正因如此，它非常适合做三件事：慵懒加载（属性用到时才算）、动态属性生成、以及给已发布类的缺失属性做向后兼容的兜底。

__getattribute__则完全不同，它在每一次属性访问时无条件触发，优先级凌驾于普通查找、__getattr__之上。我在实际项目里很少去重写__getattribute__，因为它一旦写出问题，影响的不是某个属性，而是这个对象的所有属性访问，包括方法名和特殊方法。如果你真的需要这种级别的控制，一个固定需要注意的细节是：在__getattribute__里访问别的属性时，不要再走self.xxx，不然会无限递归，应该改走object.__getattribute__(self, "xxx")。

__setattr__是另一个高频拦截点。每次给实例属性赋值，都会调用它。它很强大，但也是无限递归的重灾区。因为你在__init__里用self.name = xxx这种写法，其实就是在调用__setattr__；如果__setattr__内部又写了self.name = xxx，就会自己调自己，直接RecursionError。正确姿势是用object.__setattr__(self, "name", value)来绕过自己的拦截逻辑。同理，__delattr__里删除属性时也要走object.__delattr__(self, "name")。

给你看一个我实际用过的简化版配置对象。它实现了三个能力：属性赋值时做类型校验、冻结后拒绝修改、读取不存在属性时返回默认值而不是抛异常：

class Config: _frozen = False def __init__(self, **kwargs): for key, value in kwargs.items(): object.__setattr__(self, key, value) def __setattr__(self, name, value): if self._frozen: raise AttributeError("配置已冻结，不能修改") if not isinstance(name, str) or not name.isidentifier(): raise ValueError("非法属性名") object.__setattr__(self, name, value) def __getattr__(self, name): if name.startswith("_"): raise AttributeError(name) return None def freeze(self): object.__setattr__(self, "_frozen", True)

注意我在__getattr__里对下划线开头的属性名兜底抛出了AttributeError。这个细节很重要，因为框架代码、调试工具经常访问这类"私有"属性，如果__getattr__什么都不判断就返回None，会让一些依赖异常来感知属性不存在的逻辑失效。一个有经验的开发者会在重写__getattr__时，对所有可能是"内部约定"的属性名保持谨慎。

属性拦截器真正的价值在于，它把 Python 对象从"默认的属性容器"变成了"可编程的行为协议"。整个对象池、内建属性、属性拦截器不是三个孤立的主题，它们在我做框架设计时经常同时出现：对象池决定了内部数据怎么共享和缓存，内建属性决定了对象的基础内存布局，属性拦截器则是一张可以灵活调整的"适配层"，让你对外的接口设计不必被底层机制牵着走。

6. 一次属性访问背后，对象池和内建属性的联动

把前面这几块内容拼起来看，一个很明显的结论是：Python 对象不是孤零零的一块内存，它的行为由"底层的值对象缓存"和"顶层的属性访问协议"共同决定。举个具体场景——你访问user.name：

解释器先要通过类型对象找到user的类，查看类及 MRO 链上有没有定义name描述符，没有再去实例的__dict__里找，如果依然没有，才会轮到你可能重写的__getattr__。这一整条链路走的都是object.__getattribute__提供的默认逻辑。而name这个字符串本身，无论是属性名还是值，如果内容相同，很可能已经被 intern 机制复用了同一个字符串对象。至于user、name这些标识符，早在模块编译阶段就被驻留，因此属性的名字比较和存储也能吃到驻留的福利。至于"池"的部分，则是在创建值对象（整数、字符串）时决定它们是否共享同一份内存。

从这个联动里可以提炼出几个写代码时值得长期遵守的策略。第一，多用==，少用is，除非你明确知道自己在比较单例、比较None、或者已经显式intern过的字符串。第二，关注对象生命周期，而不是盯着某一次的结果。你在 REPL 里测出小整数池、自动驻留、free list 的各种"巧合"，很可能换个代码块、换个版本就变了。第三，想控制内存和性能，优先从数据规模和实例数量入手，比如大量重复字符串用sys.intern，大量小对象用__slots__，这两个手段的收益最容易测量。

我自己的习惯是给团队定三条简单的编码红线：一，所有对象比较都用==；二，除了判单例外不用is；三，所有重写__setattr__的类，必须在单元测试里覆盖初始化路径和冻结路径。这些看似保守的规则，恰恰是从那几次线上诡异 bug 里换回来的教训。Python 的内存管理机制设计得很精妙，但精妙的背面就是细节多、版本差异大，与其去赌某个机制的"巧合表现"，不如先把代码写到"不依赖机制也能正确"的健壮程度。这样才能既享受对象池带来的性能红利，又不被它偶尔的"意外行为"绊倒。