python内存管理含引用计数、分代垃圾回收和内存池三机制：引用计数实时追踪但难解循环引用；gc模块分三代回收，越老扫描越少；pymalloc优化小对象分配。
Python 的内存管理机制是面试中常被深挖的底层知识点，尤其在考察候选人对语言本质的理解深度时高频出现。核心不在于背概念，而在于能否说清“对象怎么分配、引用怎么计数、垃圾何时回收、哪些情况会出问题”。
引用计数：最直接但易被忽略的陷阱
Python 主要靠引用计数（Reference Counting）实时追踪对象生命周期。每个对象头里存着一个整数，记录当前有多少变量或数据结构指向它。赋值、放进容器、作为参数传入函数——都会让计数+1；变量离开作用域、从容器中删除、显式 del ——都会让计数−1。计数归零，对象立即被释放。
但要注意几个典型坑：
- 循环引用会导致引用计数无法归零（比如两个对象互相持有对方的引用），这时仅靠引用计数无法回收，必须依赖后面的循环垃圾回收器（gc 模块）
- 小整数（−5 到 256）和短字符串会被缓存并复用，它们的引用计数可能远超预期，不能用来判断对象是否“刚创建”
- 使用 sys.getrefcount(obj) 查看引用数时，传参本身会让计数临时+1，结果比实际多 1
垃圾回收器（GC）：补引用计数的短板
Python 的 gc 模块采用“分代回收”策略，把对象按存活时间分为三代（0/1/2）。新对象进第 0 代；每次第 0 代回收后还活着的对象，升到第 1 代；再活过一轮，升到第 2 代。越老的对象，扫描频率越低，提升效率。
立即学习“Python免费学习笔记（深入）”；
GC 不是全自动无感的：
- 默认开启，但可调用 gc.disable() 关闭，适合性能敏感且确认无循环引用的场景（如某些嵌入式或数值计算流程）
- gc.collect(generation=0) 可手动触发某一代回收，调试内存泄漏时常用
- 对象若定义了 __del__ 方法，会被放入特殊链表，GC 处理更谨慎，可能延迟回收甚至引发不可预测行为，应尽量避免
内存池机制（Pymalloc）：小对象分配快的关键
为减少频繁向操作系统申请/释放小内存块（
这意味着：
- 用 psutil.Process().memory_info().rss 看到的进程内存占用，可能远大于实际 Python 对象总大小（因为池中空闲块未释放）
- 即使删掉大量小对象，RSS 也不一定下降——这是正常现象，不是内存泄漏
- 大对象（≥512B）仍走系统 malloc，不受内存池管理
常见面试追问与应对要点
面试官常从现象反推机制，比如：
- “为什么 del a 后内存没降？” → 回答要分两层：一是引用计数未必归零（还有其他引用），二是小对象回收后内存块仍在池中待复用
- “list.append() 很多次后内存猛涨，怎么分析？” → 先用 sys.getsizeof() 看 list 本身大小（注意它只算容器开销，不含元素），再用 objgraph 或 gc.get_objects() 统计对象数量，定位是否产生大量未释放中间对象
- “如何写一个不会导致循环引用的观察者模式？” → 推荐用 weakref.WeakKeyDictionary 或 weakref.ref 存储回调，避免强引用闭环
