Python.四.(一)--1.内存管理与底层原理（进阶）

Python 内存管理与底层原理

Python的深拷贝与浅拷贝

赋值与引用

在Python中，用一个变量给另一个变量赋值，其实就是给当前内存中的对象增加一个"标签"而已。

>>> a = [6, 6, 6, 6] >>> b = a >>> print(id(a), id(b), sep='\n') 66668888 66668888 >>> a is b True # a 和 b 指向内存中同一个对象

浅拷贝

浅拷贝是指创建一个新的容器对象，其内容是原对象中元素的引用（新容器与原容器共享内存中的子对象）。

说明：浅拷贝和深拷贝的区别仅对可变的组合对象有意义。对于不可变类型（数字、字符串、元组——当其元素也都不可变时），由于不可变性保证，拷贝操作返回的都是原对象的引用（解释器可能做优化但语义等价）。Python 官方术语是immutable（不可变类型）vsmutable（可变类型）。

常见的浅拷贝方式

>>> import copy >>> a = [6, 8, 9] >>> b = list(a) >>> print(id(a), id(b)) 4493469248 4493592128 # a 和 b 是不同的 list 对象 >>> for x, y in zip(a, b): ... print(id(x), id(y)) 4489786672 4489786672 4489786736 4489786732 4489786768 4489786768 # 但是它们的子元素指向相同的 int 对象 —— 这就是浅拷贝的本质

从上面的例子中可以看出，a 浅拷贝得到 b，a 和 b 指向内存中不同的 list 对象，但是它们的元素指向相同的 int 对象，这就是浅拷贝。

深拷贝

深拷贝是指创建一个新的对象，然后递归地拷贝原对象所包含的所有子对象。深拷贝出来的对象与原对象及其子对象完全独立，修改任何一个都不会影响另一个。

标准库中通用的深拷贝方式是copy.deepcopy函数。此外，用户可以通过实现__deepcopy__自定义深拷贝行为；对于特定类型也可以用序列化/反序列化模拟深拷贝（如pickle.loads(pickle.dumps(obj))）；某些第三方库也可能提供自己的深拷贝实现。

>>> a = [[6, 6], [8, 8], [9, 9]] >>> b = copy.copy(a) # 浅拷贝 >>> c = copy.deepcopy(a) # 深拷贝 >>> print(id(a), id(b)) # a 和 b 是不同的外层列表 4493780304 4494523680 >>> for x, y in zip(a, b): # 但子元素相同！ ... print(id(x), id(y)) 4493592128 4493592128 4494528592 4494528592 4493779024 4493779024 >>> print(id(a), id(c)) # 深拷贝：外层不同 4493780304 4493469248 >>> for x, y in zip(a, c): # 子元素也不同！完全独立 ... print(id(x), id(y)) 4493592128 4493687696 4494528592 4493686336 4493779024 4493684896

__copy__与__deepcopy__自定义协议

copy模块允许类通过定义特殊方法来控制自己的拷贝行为：

import copy class Node: def __init__(self, value, children=None): self.value = value self.children = children or [] self._cached_hash = None # 缓存属性 def __copy__(self): """浅拷贝：创建新 Node，共享 children 列表""" new_node = Node(self.value, self.children) # 共享 children！ return new_node def __deepcopy__(self, memo): """深拷贝：递归复制所有子节点""" # memo 是 deepcopy 的内部字典，用于处理循环引用 # 防止无限递归：先检查是否已经拷贝过 if id(self) in memo: return memo[id(self)] new_node = Node(self.value) memo[id(self)] = new_node # 先注册，防止循环引用时无限递归 new_node.children = copy.deepcopy(self.children, memo) return new_node # 测试 root = Node(1, [Node(2), Node(3)]) shallow = copy(root) # 调用 __copy__ deep = copy.deepcopy(root) # 调用 __deepcopy__ # 修改深拷贝不影响原对象 deep.children[0].value = 999 print(root.children[0].value) # 2 ✓ 不受影响 # 浅拷贝的 children 是共享的 shallow.children[0].value = 888 print(root.children[0].value) # 888 ⚠️ 原对象被影响

关键点：

• __deepcopy__的memo参数必须正确处理，否则遇到循环引用会栈溢出
• __copy__不需要memo参数（不递归）
• 如果不定义这些方法，copy模块会用默认逻辑（对__dict__进行操作）

性能对比与选择指南

import time import copy # 性能对比 large_list = [[i] * 100 for i in range(10000)] start = time.perf_counter() for _ in range(10): shallow = copy.copy(large_list) print(f"浅拷贝 10 次: {time.perf_counter() - start:.4f}s") start = time.perf_counter() for _ in range(10): deep = copy.deepcopy(large_list) print(f"深拷贝 10 次: {time.perf_counter() - start:.4f}s") # 典型输出： # 浅拷贝 10 次: 0.0012s # 深拷贝 10 次: 2.8431s ← 差距可达 3 个数量级

选择建议：

• 优先用浅拷贝：当你只需要一个独立的外层容器，且不会修改子对象时
• 必须用深拷贝：当你需要完全隔离的副本，任何层级的修改都不应互相影响时
• 考虑替代方案：如果数据结构很深很大，考虑用不可变数据结构（如namedtuple、dataclass(frozen=True)）从根源避免问题

常见陷阱与防御性编程

陷阱 1：浅拷贝后意外修改共享子对象

# ❌ 经典错误 rows = [[0] * 3] * 3 # 这不是包含 3 个独立列表的列表！ rows[0][0] = 99 print(rows) # [[99, 0, 0], [99, 0, 0], [99, 0, 0]] ← 三行全变了！ # ✅ 正确做法 rows = [[0] * 3 for _ in range(3)] # 每行是独立的列表

陷阱 2：默认参数的可变陷阱（与浅拷贝相关）

# ❌ 危险：默认参数只求值一次 def append_to(item, lst=[]): # 这个 [] 在定义时就创建了！ lst.append(item) return lst append_to(1) # [1] append_to(2) # [1, 2] ← 累积了！ # ✅ 正确做法 def append_to(item, lst=None): if lst is None: lst = [] # 每次调用都创建新的 lst.append(item) return lst

陷阱 3：深拷贝的特殊对象限制

import copy # 有些对象无法被深拷贝 def foo(): pass try: copy.deepcopy(foo) except TypeError as e: print(f"无法深拷贝: {e}") # 无法深拷贝: cannot pickle 'function' object # 模块、线程锁、文件对象等也无法深拷贝

5. Python的垃圾回收机制

在Python中，使用引用计数进行垃圾回收；同时通过标记-清除算法解决容器对象可能产生的循环引用问题；最后通过分代回收算法提高垃圾回收效率。

Python 的垃圾回收（Garbage Collection, GC）采用三合一策略：

┌─────────────────────────────────────────────────────────┐ │ Python GC 三大机制 │ ├──────────────┬──────────────────┬────────────────────────┤ │ ① 引用计数 │ ② 标记-清除 │ ③ 分代回收 │ │ (主要机制) │ (处理循环引用) │ (优化 GC 效率) │ │ 即时回收 │ 定期执行 │ 分代管理 │ │ 无需暂停 │ 需要 STW 暂停 │ 降低扫描频率 │ └──────────────┴──────────────────┴────────────────────────┘

机制一：引用计数（Reference Counting）— 主要回收方式

核心原理

每个 Python 对象头部都有一个ob_refcnt字段（CPython 实现），记录当前有多少个引用指向该对象。

PyObject_HEAD { Py_ssize_t ob_refcnt; // 引用计数 struct _typeobject *ob_type; // 类型指针 }

引用计数变化规则

关键特性

# 引用计数的即时性：一旦归零，立刻回收 import sys a = [1, 2, 3] print(sys.getrefcount(a)) # 2（1 个 a + getrefcount 临时引用） b = a print(sys.getrefcount(a)) # 3 del b print(sys.getrefcount(a)) # 2 del a # 此时 [1,2,3] 的引用计数为 0，立即被销毁 # 不需要等待任何 GC 周期

优点：

• 即时性：引用归零立即回收，无延迟
• 可预测：回收时机确定，适合管理资源（文件句柄、锁）
• 无需暂停：不需要 STW（Stop-The-World）暂停

缺点：

• 无法处理循环引用（需要辅助机制）
• 每次赋值/删除都有开销（ob_refcnt的原子操作）
• 线程安全依赖 GIL（引用计数操作不是原子操作，但 GIL 保护了它）

机制二：标记-清除（Mark-Sweep）— 解决循环引用

为什么需要？

引用计数无法处理的场景：

# 循环引用：两个对象的引用计数永远不会归零 class A: def __init__(self): self.ref = None a = A() # a 的 A 实例: refcount=1 b = A() # b 的 A 实例: refcount=1 a.ref = b # b 的 refcount=2 b.ref = a # a 的 refcount=2 del a # a 的 A 实例: refcount=1（b.ref 还在引用） del b # b 的 A 实例: refcount=1（a.ref 还在引用） # 两个对象互相引用，refcount 都是 1，永远无法归零！ # 这就是引用计数的根本缺陷

标记-清除算法流程

Python 的 GC 只针对容器对象（list, dict, class instance, tuple 等）进行循环引用检测：

步骤 1: 收集所有容器对象（根节点） ↓ 步骤 2: 标记（Mark）—— 从 GC Roots 出发遍历 - GC Roots 包括：全局变量、栈上的局部变量、正在执行的帧 - 能到达的对象标记为 "reachable" ↓ 步骤 3: 清除（Sweep）—— 回收不可达对象 - 未被标记的对象就是垃圾 - 将其引用计数强制归零，触发 __del__，释放内存

import gc import sys class B: def __init__(self, name): self.name = name self.partner = None def __del__(self): print(f"{self.name} 被销毁了") # 创建循环引用 x = B("X") y = B("Y") x.partner = y y.partner = x print(f"删除前: x_ref={sys.getrefcount(x)}, y_ref={sys.getrefcount(y)}") del x, y # 外部引用删除，但 x 和 y 仍互相引用 # 手动触发 GC collected = gc.collect() print(f"GC 回收了 {collected} 个对象") # 输出： # X 被销毁了 # Y 被销毁了 # GC 回收了 2 个对象

触发条件（阈值机制）

import gc # 查看当前 GC 阈值 print(gc.get_threshold()) # 输出: (700, 10, 5) # 含义： # 第 0 代：新建对象数 - 删除对象数 > 700 时，触发第 0 代 GC # 第 1 代：第 0 代 GC 累计执行 10 次后，触发第 1 代 GC # 第 2 代：第 1 代 GC 累计执行 5 次后，触发第 2 代 GC # 自定义阈值（针对你的应用调优） gc.set_threshold(1000, 15, 5)

机制三：分代回收（Generational Collection）— 优化效率

分代假设（Generational Hypothesis）

大部分对象的生命周期都很短（分代假设）。Python 据此将对象分为三代：

Generation 0 (年轻代): 新创建的容器对象 │ ├── 经历一次 GC 后仍然存活 → 晋升到 Generation 1 │ Generation 1 (中年代) │ ├── 经历一次 GC 后仍然存活 → 晋升到 Generation 2 │ Generation 2 (老年代): 长期存活的对象

import gc # 查看各代的对象计数 print(gc.get_count()) # 例如 (123, 5, 1) # 含义：(Gen0 当前差值, Gen1 当前差值, Gen2 当前差值) # 查看各代的统计信息（Python 3.4+） for i, stat in enumerate(gc.get_stats()): print(f"Gen {i}: collections={stat['collections']}, " f"collected={stat['collected']}, " f"uncollectable={stat['uncollectable']}")

为什么分代有效？

核心思想：花大部分时间扫描 Gen 0（快速清理大量短命对象），很少去扫 Gen 2（避免不必要的开销）。

GC 调优与调试

手动控制 GC

import gc # 禁用自动 GC（特殊场景下使用，如实时游戏渲染） gc.disable() # ... 执行关键路径 ... # 手动触发一次完整 GC gc.collect() # 重新启用自动 GC gc.enable()

调试循环引用

import gc # 启用调试模式 gc.set_debug(gc.DEBUG_STATS) # 设置未回收对象的回调 gc.set_debug(gc.DEBUG_SAVEALL) gc.collect() # 查看 GC 的 garbage 列表（未被回收的对象在这里） print(len(gc.garbage))

GC 暂停（GC Pause）对性能的影响

在高并发/低延迟服务中，GC pause 可能导致请求超时。解决方案：

1. 降低 GC 频率：gc.set_threshold(更高阈值)
2. 在低峰期手动collect()
3. 使用增量式 GC（Python 版本演进方向）

11. Python中的引用计数原理，如何消除一个变量上的所有引用计数？

Python 中的引用计数是垃圾回收机制的主要组成部分，用来跟踪对象的引用数量。每个对象内部维护一个引用计数器，当计数器归零时对象立即被销毁。

引用计数原理

1. 创建对象：当创建一个对象时，其引用计数初始化为 1。
2. 增加引用：每当有一个新的引用指向该对象时（例如，将对象赋值给一个变量或将其添加到一个数据结构中），对象的引用计数增加。
3. 减少引用：每当一个引用不再指向该对象时（例如，变量被重新赋值或被del删除），对象的引用计数减少。
4. 删除对象：当对象的引用计数降到 0 时，表示没有任何引用指向该对象，Python 的垃圾回收器就会销毁该对象并释放其占用的内存。

代码示例

# 创建对象 a = [1, 2, 3] # 引用计数为 1 # 增加引用 b = a # 引用计数为 2 c = a # 引用计数为 3 # 减少引用 del b # 引用计数为 2 c = None # 引用计数为 1 del a # 引用计数为 0，对象被销毁

获取对象的引用计数

可以使用sys模块中的getrefcount函数来获取对象的引用计数：

import sys a = [1, 2, 3] print(sys.getrefcount(a)) # 通常会比预期多 1，因为 getrefcount 本身也会创建一个临时引用传入参数

CPython 底层实现

// Include/object.h (CPython 源码) typedef struct _object { Py_ssize_t ob_refcnt; // 引用计数（有符号整数） struct _typeobject *ob_type; // 类型指针 } PyObject; // 引用计数增加宏 #define Py_INCREF(op) ((op)->ob_refcnt++) // 引用计数减少宏（可能触发销毁） #define Py_DECREF(op) \ do { \ if (--((op)->ob_refcnt) == 0) \ _Py_Dealloc((PyObject *)(op)); \ } while (0)

关键点：

• ob_refcnt是Py_ssize_t（平台相关的有符号整数，通常 64 位系统上是 64 位）
• Py_INCREF/Py_DECREF不是线程安全的原子操作，但GIL 保护了它们
• 当Py_DECREF使计数归零时，立即调用_Py_Dealloc→tp_dealloc→__del__→ 释放内存

弱引用（weakref）—— 不增加引用计数

import weakref import sys class BigObject: def __init__(self, name): self.name = name def __del__(self): print(f"{self.name} 被销毁") obj = BigObject("大数据") # 弱引用：不增加 ob_refcnt！ ref = weakref.ref(obj) print(sys.getrefcount(obj)) # 2（obj 变量 + getrefcount 临时） # weakref.ref 不计入！ # 通过弱引用访问对象 print(ref().name) # "大数据"（如果对象还活着的话） # 删除强引用 del obj # BigObject 被销毁！（因为只剩弱引用了） print(ref()) # None（对象已被销毁，弱引用返回 None）

弱引用的应用场景：

• 缓存：缓存对象但不阻止其被回收
• 观察者模式：观察者持有被观察者的弱引用，避免循环引用
• 双向关联：parent↔child 关系中，child→parent 用弱引用

# 观察者模式的经典用法 class Subject: def __init__(self): self._observers = [] def attach(self, observer): # 使用弱引用避免 observer 无法被回收 self._observers.append(weakref.ref(observer)) def notify(self, event): for obs_ref in self._observers: observer = obs_ref() if observer is not None: # 检查是否还活着 observer.update(event) else: self._observers.remove(obs_ref) # 清理死引用

如何系统性地消除所有引用

import gc import sys import weakref class Resource: """示例：需要管理的资源""" def __init__(self, data): self.data = data def __del__(self): print(f"Resource({self.data}) 被销毁") # === 场景：消除对象上的所有引用 === # 1. 创建对象和多处引用 obj = Resource("重要数据") container_list = [obj] container_dict = {"key": obj} global_ref = obj # 模拟全局变量 print(f"初始引用计数: {sys.getrefcount(obj)}") # 可能输出 5 或更多（取决于解释器内部临时引用） # === 第一步：删除直接变量引用 === obj = None # 注意：del 只是删除名称绑定，不是删除对象本身 # === 第二步：清除容器中的引用 === container_list.clear() # 清空列表 del container_dict["key"] # 从字典移除 # === 第三步：清除全局/模块级引用 === global_ref = None # === 第四步：检查是否有隐藏引用 === # 常见隐藏来源： # - 异常对象的 __traceback__（Python < 3.7 会持有栈帧引用） # - 闭包捕获的变量 # - weakref 回调 # - threading.local 存储 # === 第五步：处理可能的循环引用 === collected = gc.collect() print(f"GC 回收了 {collected} 个对象") # === 第六步：验证 === # 如果对象真的被销毁了，你应该看到 __del__ 的打印输出

系统性检查清单：

# 高级调试：找出谁还在引用某个对象 import gc target_obj = [1, 2, 3] # 获取所有引用 target_obj 的对象 referrers = gc.get_referrers(target_obj) for i, referrer in enumerate(referrers): print(f"引用者 #{i}: type={type(referrer)}, value={referrer}")

循环引用问题

循环引用会导致引用计数无法正常工作，这时需要依靠 Python 的垃圾回收器来检测和处理循环引用。

import gc class Node: def __init__(self, value): self.value = value self.ref = None def __del__(self): print(f"Node({self.value}) 被销毁") # 创建循环引用 n1 = Node(1) n2 = Node(2) n1.ref = n2 n2.ref = n1 # 即使手动将 n1 和 n2 设置为 None，互相的引用仍然存在 del n1, n2 # 强制垃圾回收以清除循环引用 gc.collect() # Node(1) 被销毁 # Node(2) 被销毁

Python中什么情况下会产生内存泄漏？

内存泄漏（Memory Leak）概念

内存泄漏是指程序在运行过程中申请内存却未能正确释放，从而导致内存占用不断增加，最终可能耗尽系统内存。虽然 Python 有自动垃圾回收机制（引用计数 + 循环引用 GC），但在某些特定场景下依然会产生内存泄漏。

Python 中的内存管理机制（简述）

1. 引用计数：变量引用对象时计数+1，取消引用时-1，归零即释放
2. 垃圾回收器（gc 模块）：专门处理循环引用，定期检测并回收不可达的容器对象

虽然 Python 具备上述机制，但仍有可能在某些情况下导致内存泄漏，特别是在复杂应用程序中。下面是 Python 中几种常见的可能导致内存泄漏的场景：

1. 循环引用（Cyclic References）

当两个或多个对象互相引用对方时，虽然它们都已经没有被外部引用，但由于引用计数无法降为0，垃圾回收机制无法自动释放它们，从而导致内存泄漏。

class A: def __init__(self): self.ref = None a1 = A() a2 = A() # a1 和 a2 互相引用 a1.ref = a2 a2.ref = a1 # 即使手动将 a1 和 a2 设置为 None，互相的引用仍然存在 a1 = None a2 = None # 此时内存中的两个对象都无法通过引用计数机制回收 # 需要等待 GC 的标记-清除来处理

解决方法：

• 使用gc.collect()来手动触发垃圾回收器，强制收集这些循环引用的对象
• 尽量避免对象之间的相互引用，或者使用weakref模块创建弱引用来打破引用链条

2. 全局变量或静态对象

如果某些对象被保存为全局变量或静态对象，它们的生命周期可能会持续到程序结束，导致它们的内存一直占用不释放。

global_list = [] def add_to_list(): for i in range(100000): global_list.append(i) # 每次调用这个函数，global_list 会不断增长，无法释放内存

解决方法：

• 尽量减少不必要的全局变量，确保及时清空或删除全局变量中的不必要数据
• 当某个全局对象不再需要时，可以通过del或者重置为None来释放它们

3. 未关闭的文件或网络连接

当打开文件或网络连接时，如果没有显式关闭这些资源，它们会一直占用内存。特别是在循环中不断打开资源但未关闭时，可能会造成内存泄漏。

推荐做法：始终使用上下文管理器（with语句）来自动管理资源的生命周期。

# ✅ 推荐：使用 with 语句确保资源正确关闭 with open('large_file.txt', 'r') as f: data = f.read() # 离开 with 块后文件自动关闭

4. C 扩展/CFFI 分配的内存泄漏

这是 Python 内存泄漏中最容易被忽视也最危险的一类。C 扩展通过malloc分配的内存，Python GC 完全管不到！

import numpy as np def process_leak(): # 某些 C 扩展操作可能在 C 层面分配内存 arr = np.zeros((10000, 10000)) # ~800MB 在 C 层面分配 # 如果这个数组被 C 扩展内部缓存引用了， # 即使 del arr，C 层面的内存也不会释放 return arr.sum() # 反复调用可能导致 OOM for i in range(1000): process_leak()

排查方法：

# 使用 tracemalloc 追踪 C 层面内存分配 import tracemalloc tracemalloc.start(25) # 记录最近 25 个分配的堆栈 # ... 执行可疑代码 ... snapshot = tracemalloc.take_snapshot() top_stats = snapshot.statistics('lineno') for stat in top_stats[:10]: print(stat) tracemalloc.stop()

5.__del__+ 循环引用泄漏陷阱

这是一个非常微妙的坑：有__del__的对象参与循环引用时，GC 不知道安全的销毁顺序，这些对象会被移入gc.garbage列表，永远不会被自动回收。

import gc class BadNode: def __init__(self): self.ref = None def __del__(self): print("BadNode.__del__ 被调用") # 制造循环引用 a = BadNode() b = BadNode() a.ref = b b.ref = a del a, b # 删除外部引用 collected = gc.collect() print(f"回收数量: {collected}") # 检查 gc.garbage —— 未回收的对象在这里！ if gc.garbage: print(f"⚠️ 有 {len(gc.garbage)} 个对象无法被 GC 回收！") # 必须手动打破循环引用 for obj in gc.garbage: obj.ref = None # 打破循环 gc.garbage.clear() gc.collect() # 再次尝试回收

解决方案：

方案 1：使用weakref打破循环

import weakref class GoodNode: def __init__(self): self.ref = None def set_partner(self, other): self.ref = weakref.ref(other) # 弱引用，不增加计数

方案 2：支持上下文管理器显式关闭

class SafeNode: def __init__(self): self.ref = None def close(self): if self.ref is not None: partner = self.ref self.ref = None if partner is not None and partner.ref is not None: partner.ref = None def __enter__(self): return self def __exit__(self, *args): self.close() with SafeNode() as node1, SafeNode() as node2: node1.ref = node2 node2.ref = node1 # exit 时自动 close()，打破循环

6. 闭包捕获泄漏

闭包可能意外延长大对象的生命周期：

def create_handler(): big_data = [i for i in range(1000000)] # ~8MB 数据 def handler(event): # 闭包捕获了 big_data，即使 handler 不需要它 print(f"处理事件: {event}") return handler h = create_handler() # 此时 big_data 不会被释放！handler 活着，big_data 就活着 # 即使 handler 永远不会用到 big_data # ✅ 正确做法：只在闭包中捕获需要的变量 def create_handler_fixed(): big_data = [i for i in range(1000000)] summary = sum(big_data) # 只提取需要的数据 def handler(event): print(f"处理事件: {event}, 总和={summary}") # 只捕获 summary return handler

检测方法：

# 检查闭包捕获了哪些变量 def check_closure(func): if func.__closure__: for i, cell in enumerate(func.__closure__): free_var = func.__code__.co_freevars[i] obj = cell.cell_contents print(f"闭包变量 '{free_var}': type={type(obj).__name__}, size={sys.getsizeof(obj)}") else: print("没有闭包捕获")

7. 其他常见泄漏场景

缓存无限增长

# ❌ 无限增长的缓存 _cache = {} def expensive_func(key): if key not in _cache: _cache[key] = compute_expensive(key) # 永远不清理 return _cache[key] # ✅ 使用 LRU 缓存（有限大小） from functools import lru_cache @lru_cache(maxsize=128) # 最多缓存 128 个结果 def expensive_func_fixed(key): return compute_expensive(key)

生成器/迭代器未消费

def read_big_file(path): with open(path) as f: yield from f # 生成器持有文件句柄 gen = read_big_file("huge.dat") next(gen) # 读了一行 # 如果忘记继续消费 gen 或关闭它，文件句柄一直开着！ # ✅ 确保资源释放 gen = read_big_file("huge.dat") try: for line in gen: process(line) if some_condition: break finally: gen.close() # 显式关闭生成器

traceback 保持引用（Python < 3.7）

# Python < 3.7: 异常对象的 .__traceback__ 持有完整栈帧 # 栈帧包含所有局部变量的引用 def leak_via_exception(): big_data = bytearray(10**8) # 100MB try: 1 / 0 except Exception as e: return e # 返回异常对象，e.__traceback__ 引用了 big_data！ exc = leak_via_exception() # 此时 100MB 的 big_data 无法被回收！ # 因为 exc.__traceback__ → frame → f_locals → big_data # ✅ Python >= 3.7 默认不保存 traceback # 或手动清除： exc.__traceback__ = None

内存泄漏排查工具箱

# ===== 综合内存泄漏排查方案 ===== # 工具 1: tracemalloc（标准库，推荐首选） import tracemalloc import gc tracemalloc.start() # ... 运行程序 ... snapshot1 = tracemalloc.take_snapshot() # ... 执行可疑操作 ... snapshot2 = tracemalloc.take_snapshot() top_stats = snapshot2.compare_to(snapshot1, 'lineno') for stat in top_stats[:10]: print(stat) tracemalloc.stop() # 工具 2: objgraph（第三方，可视化对象引用关系） # pip install objgraph # import objgraph # objgraph.show_most_common_types(limit=20) # objgraph.show_refs(some_object, max_depth=3) # 可视化引用链 # objgraph.show_backrefs([some_object], max_depth=3) # 谁引用了它 # 工具 3: gc 模块内置调试 gc.set_debug(gc.DEBUG_STATS | gc.DEBUG_UNCOLLECTABLE | gc.DEBUG_INSTANCES | gc.DEBUG_OBJECTS) gc.collect() print(f"不可回收对象数: {len(gc.garbage)}") # 工具 4: memory_profiler（逐行内存监控） # pip install memory_profiler # @profile # def my_func(): # ... # 运行: python -m memory_profiler script.py # 工具 5: pympler（第三方，详细的内存统计） # from pympler import muppy, summary # all_objects = muppy.get_objects() # summ = summary.summarize(all_objects) # summary.print_(summ, limit=20)

内存泄漏排查流程图

发现内存占用持续增长 │ ▼ ┌─ 是否使用了 C 扩展？ ──┐ │ YES │ NO ▼ ▼ 用 tracemalloc 排查 检查全局变量 C 层面内存分配 检查循环引用 + __del__ 检查闭包捕获 检查缓存大小 │ │ └───────┬────────┘ ▼ 用 gc.get_referrers() 找出谁还在引用 │ ▼ 用 objgraph 可视化引用链 │ ▼ 修复 + 验证（回归测试 + 内存基线监控）

总结：四大主题的核心知识图谱

Python 内存管理全景 │ ├── 1. 垃圾回收机制（Topic 5） │ ├── 引用计数（主）：即时、确定、有循环盲区 │ ├── 标记-清除（辅）：定期扫描、处理循环、STW 暂停 │ └── 分代回收（优化）：Gen0/1/2、分代假设、降低开销 │ ├── 2. 引用计数原理（Topic 11） │ ├── ob_refcnt 底层字段 │ ├── INCREF/DECREF 宏 │ ├── 弱引用（weakref）绕过计数 │ ├── getrefcount 陷阱（+1） │ └── 系统性消除引用的方法论 │ ├── 3. 内存泄漏场景（Topic 16） │ ├── 循环引用（GC 可处理但有例外） │ ├── __del__ + 循环引用（⚠️ GC 无法处理！） │ ├── C 扩展泄漏（⚠️ GC 完全管不到） │ ├── 全局变量 / 闭包 / 缓存增长 │ ├── 资源未释放（文件/连接/生成器） │ └── 排查工具：tracemalloc > objgraph > gc.debug > pympler │ └── 4. 深拷贝与浅拷贝（Topic 4） ├── 赋值 ≠ 拷贝（只是加标签） ├── 浅拷贝：新容器 + 共享子对象 ├── 深拷贝：递归复制 + 完全独立 ├── __copy__ / __deepcopy__ 自定义协议 ├── 性能差异（可能 1000x+） └── 选择指南：默认浅拷贝，需要隔离时才深拷贝