Python 内存管理深度解析

本文适合有 Java 背景、正在学习 Python 的开发者。用熟悉的术语类比，从对象布局到分配、回收、优化、排查，系统性介绍 Python 内存管理。

写在前面

在学习 Python 的过程中，我发现 Python 的内存管理与 Java 有着本质的不同——我看到的资料大多要么只讲引用计数，要么直接分析 CPython 源码，缺少一个中间视角。

一句话总结：Python 的内存管理是"有 GC 辅助的引用计数系统，带着一些’够用就行’的工程妥协"。

本文从底层到上层，覆盖 8 个核心主题：

下面逐一展开。

一、对象的内存表示

1.1 PyObject：每个对象的"身份证"

Python 中一切皆对象。每个对象在 C 层面都是一个 PyObject 结构体，包含两个固定字段：

┌──────────────────────────────────┐
│ PyObject (16 bytes) │
├────────────────┬─────────────────┤
│ ob_refcnt │ ob_type │
│ (8 bytes) │ (8 bytes) │
│ 引用计数 │ 类型指针 │
└────────────────┴─────────────────┘

• ob_refcnt：引用计数，决定对象何时被回收
• ob_type：指向类型对象的指针（如 int、str、自定义类）

这 16 字节是每个 Python 对象的"最低消费"。类比 Java 对象头（Mark Word + Klass 指针），但 Python 的对象头更简单——没有 GC 标记位、没有哈希缓存、没有锁信息。

1.2 各类型的内存开销

不同类型在 PyObject 头之上还有各自的额外字段：

import sys

print(sys.getsizeof(0)) # 28
print(sys.getsizeof(1.0)) # 24
print(sys.getsizeof("")) # 49
print(sys.getsizeof([])) # 56
print(sys.getsizeof({})) # 72
print(sys.getsizeof(())) # 40

注意：sys.getsizeof 只返回对象本身大小，不包含引用对象。详见第七节。

1.3 可变与不可变对象

Python 对象分为可变（mutable）和不可变（immutable）：

不可变对象 可变对象
─────────────────────────────────────────
int, float, str, tuple list, dict, set
bytes, frozenset, bool 自定义类（默认）

修改 = 创建新对象 修改 = 原地修改

# 不可变：每次"修改"都创建新对象
s = "hello"
print(id(s)) # 140234567890000
s += " world"
print(id(s)) # 140234567890200 ← 不同对象！

# 可变：原地修改
lst = [1, 2, 3]
print(id(lst)) # 140234567890400
lst.append(4)
print(id(lst)) # 140234567890400 ← 同一对象

这对内存的影响：不可变对象的频繁"修改"会导致大量临时对象分配。类比 Java 的 String 不可变性——+= 在循环中会产生大量中间对象。

1.3 跨语言对比：Go vs Python vs Java

Python 的特点是"起步轻、增长快"——解释器本身只有几 MB，但每个值都是堆对象（int 28B、无栈上分配），数据量大时内存消耗可能超过 Java。这也是为什么第六节的内存优化手段（__slots__、memoryview）在 Python 中格外重要。

1.4 小整数缓存与字符串驻留

Python 预创建 -5 到 256 的小整数并缓存复用（类比 Java 的 IntegerCache(-128~127)）：

a = 100
b = 100
print(a is b) # True（同一个对象）

c = 1000
d = 1000
print(c is d) # False（不同对象）

字符串驻留（interning）是另一个重要优化。Python 自动驻留标识符（变量名、函数名等），也可手动驻留：

import sys

# 自动驻留：仅限标识符格式的字符串
a = "hello"
b = "hello"
print(a is b) # True（驻留了）

# 手动驻留任意字符串
c = sys.intern("some long string " * 100)
d = sys.intern("some long string " * 100)
print(c is d) # True（手动驻留，节省内存）

二、内存分配：pymalloc

2.1 Arena → Pool → Block 三层结构

CPython 使用内置分配器 pymalloc 管理小对象（≤512B），采用三层结构：

OS malloc ──▶ Arena (256KB) ──▶ Pool (4KB) ──▶ Block (8/16/24/…/512B)
↑ ↑
从 OS 申请的基本单位 实际分配给 Python 对象

• Arena：从 OS 申请的大块内存（256KB），pymalloc 的基本管理单位
• Pool：从 Arena 切分（4KB），管理相同大小的 Block
• Block：按大小分级，实际分配给 Python 对象

2.2 Block 大小分级

pymalloc 将 Block 分为 64 个大小等级，步长 8 字节：

等级 大小 等级 大小 等级 大小
0 8B 10 88B …
1 16B 11 96B 60 488B
2 24B 12 104B 61 496B
3 32B … 62 504B
… 31 256B 63 512B

每个 Pool 只管理同一等级的 Block。分配时 pymalloc 找到匹配的大小等级，从对应 Pool 中取一个空闲 Block。

2.3 大对象路径

超过 512 字节的对象绕过 pymalloc，直接使用 C 的 malloc/free：

对象大小 ≤ 512B → pymalloc (Arena/Pool/Block)
对象大小 > 512B → raw malloc / free

这类似于 Java 的 TLAB vs 直接堆分配——小对象走快速路径，大对象直接向 OS 申请。

2.4 堆与栈

Python 有堆内存，且所有对象都在堆上，栈上只存放对象的引用（类似指针）。

def my_function():
x = 42 # 整数对象 42 在堆上，引用 x 在栈上
y = [1, 2, 3] # 列表对象在堆上
# 函数返回后，x、y 引用从栈弹出，堆对象可能还在

栈上只存引用（指针），所有对象通过 pymalloc 在堆上分配。与 Java 的一个关键差异：Python 没有栈上分配（没有逃逸分析），所有对象都是堆对象。

2.5 进程内存 vs Python 对象内存

理解 Python 的内存占用，需要区分三个层次：

┌──────────────────────────────────────────────────────────────┐
│ 进程 RSS (psutil / top 看到的内存) │
│ ┌────────────────────────────────────────────────────────┐ │
│ │ pymalloc 管理的堆 (已从 OS 申请) │ │
│ │ ┌──────────────────────┐ ┌──────────────────────────┐│ │
│ │ │ Python 活跃对象 │ │ arena 缓存 ││ │
│ │ │ (tracemalloc 可统计) │ │ (已申请但无对象在用) ││ │
│ │ └──────────────────────┘ └──────────────────────────┘│ │
│ └────────────────────────────────────────────────────────┘ │
│ ┌──────────────┐ ┌────────────────────────────────────┐ │
│ │ C 扩展 malloc │ │ 其他（栈、代码段、共享库…） │ │
│ └──────────────┘ └────────────────────────────────────┘ │
└──────────────────────────────────────────────────────────────┘

tracemalloc 看到的 = Python 活跃对象（实际"使用"）
RSS – tracemalloc = arena 缓存 + C 扩展 + 其他（"占用"但不使用）

def memory_not_returned():
data = [0] * 100000000 # 分配 800MB
del data
import gc
gc.collect()
# 此时进程 RSS 仍然 ~800MB！
# 但 tracemalloc 显示 Python 对象已释放
# 差额 = arena 缓存

pymalloc 在对象释放后的归还路径：

Block 释放 → 归还给 Pool 的空闲链表
Pool 全空 → 归还给 Arena 的空闲链表
Arena → 保留不立即 munmap，供后续分配复用

这就是 del + gc.collect() 后 RSS 不降的原因——arena 层面的内存由 pymalloc 持有，不会主动归还 OS。

这种分配器缓存不归还 OS 的行为并非 Python 独有——glibc malloc 的 free() 也不立即 munmap，Java 堆 -Xms 预占后 GC 不主动缩容，Go runtime 同样保留 mspan 给后续分配。关键在于区分"Python 对象实际使用"和"进程 RSS 占用"，避免误判为内存泄漏。

三、引用计数

3.1 基本原理

引用计数是 Python 的主力回收机制。每个 PyObject 的 ob_refcnt 字段记录当前有多少引用指向它：

import sys

def refcount_demo():
x = [1, 2, 3] # 引用计数 = 1
y = x # 引用计数 = 2
print(sys.getrefcount(x) – 1) # 2（减1是因为getrefcount的临时引用）
del x # 引用计数 = 1
del y # 引用计数 = 0 → 立即回收！

3.2 Py_INCREF 与 Py_DECREF

在 C 层面，引用计数的增减通过两个宏实现：

// 增加引用计数
#define Py_INCREF(op) ((op)->ob_refcnt++)

// 减少引用计数，归零时调用 dealloc
#define Py_DECREF(op) \\
if (—(op)->ob_refcnt == 0) \\
_Py_Dealloc(op)

CPython 中这两个操作不需要显式加锁——GIL（全局解释器锁）保证了引用计数操作的原子性。这是 GIL 的一个"副作用福利"：它让引用计数变得简单高效，但也限制了多线程并行。

对比 Java：Java 没有引用计数，对象存活由 GC 的可达性分析决定，不需要在每次赋值时维护计数器。

3.3 弱引用

弱引用允许你引用一个对象但不增加它的引用计数：

import weakref

class MyClass:
pass

obj = MyClass()
ref = weakref.ref(obj) # 不增加引用计数
print(ref()) # <MyClass object> — 对象还在

del obj # 引用计数归零，对象被回收
print(ref()) # None — 弱引用自动失效

weakref.ref 内部维护一个回调链表。对象被回收时，所有指向它的弱引用自动置为 None。常见用途：缓存（WeakValueDictionary）、观察者模式、打破循环引用。

3.4 循环引用：引用计数的阿喀琉斯之踵

引用计数最大的缺陷是无法处理循环引用：

class Node:
def __init__(self, name):
self.name = name
self.next = None

a = Node("A")
b = Node("B")
a.next = b
b.next = a # 循环引用！

del a
del b
# a 和 b 互相引用，引用计数各为 1，永不归零
# → 需要分代 GC 来回收

┌─────────┐ next ┌─────────┐
│ Node A │ ─────────▶ │ Node B │
│ refcnt=1│ │ refcnt=1│
└─────────┘ ◀───────── └─────────┘
next

这就是为什么 Python 需要分代 GC——引用计数搞不定的循环引用，交给 GC 处理。

四、分代 GC

4.1 三代结构

Python 的分代 GC 将对象分为三代：

┌─────────────────────────────────────────────────────────┐
│ gen0 (年轻代) gen1 (中年代) gen2 (老年代) │
│ ┌──────────┐ ┌──────────┐ ┌──────────┐ │
│ │ 新对象 │ 晋升 │ 存活对象 │ 晋升 │ 长命对象 │ │
│ │ 阈值: 700 │ ──────▶ │ 阈值: 10 │ ────▶ │ 阈值: 10 │ │
│ │ 频率: 最高 │ │ 频率: 中 │ │ 频率: 最低 │ │
│ └──────────┘ └──────────┘ └──────────┘ │
└─────────────────────────────────────────────────────────┘

• gen0：新创建的对象。当分配次数与释放次数之差超过 700 时触发 gen0 GC
• gen1：在 gen0 GC 中存活的对象。gen0 执行 10 次后触发一次 gen1 GC
• gen2：在 gen1 GC 中存活的对象。gen1 执行 10 次后触发一次 gen2 GC

可以通过 gc.get_threshold() 查看和 gc.set_threshold() 修改阈值。

4.2 循环检测算法

分代 GC 的核心任务是找到并回收循环引用。算法思路：

1. 从所有"根对象"出发（全局变量、栈上引用、寄存器）
2. 遍历可达对象，标记为"存活"
3. 未被标记的对象 = 不可达的循环引用 → 回收

Python 的 GC 只关注容器对象（list、dict、自定义类等），因为只有容器才能形成循环引用。整数、字符串等不可变对象不会被 GC 扫描。

Python GC 的实际实现更复杂——在遍历过程中，对象间的引用关系可能因 __del__ 或弱引用回调而动态变化，CPython 通过 tp_traverse 协议和多阶段标记来处理这些情况。

import gc

# 查看各代对象数量
print(gc.get_count()) # (345, 12, 3) → gen0: 345, gen1: 12, gen2: 3

# 手动触发 GC
gc.collect() # 默认触发 gen2（全量）
gc.collect(0) # 仅触发 gen0

4.3 OOM 前不会主动 GC

与 Java 的关键差异：

# Python 不会在内存不足时主动 GC
import gc

gc.disable() # 禁用自动 GC
big_list = []

try:
while True:
big_list.append([0] * 100000) # 最终会 MemoryError，不会主动 GC
except MemoryError:
print("内存不足，但 GC 从未被触发")

4.4 常见的内存"不释放"场景

场景 1：模块级/全局缓存（真正的泄漏）

# module_cache.py
CACHE = {} # 模块级字典，永不销毁

def add_to_cache(key, value):
CACHE[key] = value # 数据一直存在

def problematic():
for i in range(1000000):
add_to_cache(i, [0] * 1000) # 内存泄漏！

场景 2：闭包意外持有大对象

def create_processor():
large_data = [0] * 100000000 # 800MB

def process(x):
return large_data[0] + x # 闭包持有 large_data

return process

func = create_processor() # 800MB 数据被 __closure__ 一直持有

这不是内存泄漏（对象通过 __closure__ 仍然可达），而是闭包抓住了比预期多得多的数据——large_data[0] 只需要一个元素，但整个 800MB 列表被持有。

场景 3：进程 RSS 不下降

详见 2.5 节。del + gc.collect() 后 RSS 不降是分配器缓存的正常行为，并非 Python 特有。

4.5 Java vs Python 思维定式对比

五、内存限制

5.1 代码内限制：resource 模块（Unix）

import resource

def limit_memory(max_mb: int):
memory_limit_bytes = max_mb * 1024 * 1024
soft, hard = resource.getrlimit(resource.RLIMIT_AS)
resource.setrlimit(resource.RLIMIT_AS, (memory_limit_bytes, hard))

limit_memory(200) # 限制 200MB
try:
huge_list = [0] * (300 * 1024 * 1024 // 8)
except MemoryError:
print("超出内存限制")

5.2 Shell 命令：ulimit

ulimit -v 524288 # 512MB 虚拟内存限制
python my_script.py

5.3 生产环境：Docker

# docker-compose.yml
services:
app:
deploy:
resources:
limits:
memory: 2G
reservations:
memory: 1G

六、内存优化

6.1 __slots__：省去实例 __dict__

Python 默认给每个实例分配 __dict__ 字典存储属性，额外开销约 64-128 bytes/实例：

# 普通类：每个实例有 __dict__
class Message:
def __init__(self, role, content):
self.role = role
self.content = content

# __slots__ 类：属性存储在固定 C 数组中
class MessageSlots:
__slots__ = ('role', 'content')
def __init__(self, role, content):
self.role = role
self.content = content

代价是不能再动态添加属性。对于大量小对象场景，__slots__ 可显著减少内存占用。

注意继承陷阱：父类定义了 __slots__，但子类如果没有定义 __slots__，子类实例依然会生成 __dict__，优化白做：

class Base:
__slots__ = ('x',)

class Derived(Base): # 没定义 __slots__
pass

d = Derived()
d.y = 42 # 可以！因为 Derived 有 __dict__
print(d.__dict__) # {'y': 42}

6.2 memoryview：零拷贝访问

memoryview 允许在不复制数据的情况下访问对象的内存缓冲区：

# 无 memoryview：切片会复制数据
data = bytearray(b"hello world")
part = data[0:5] # 创建新的 bytearray，复制 5 字节

# 有 memoryview：零拷贝
mv = memoryview(data)
part = mv[0:5] # 不复制，直接引用原始内存

适用于处理大块二进制数据、网络包解析、numpy 互操作等场景。类比 Java 的 ByteBuffer。

6.3 容器扩容策略

Python 容器的扩容策略直接影响内存使用：

# list 扩容：每次扩容约 1.125 倍
import sys
lst = []
for i in range(100):
lst.append(i)
if i % 10 == 0:
print(f"len={len(lst)}, size={sys.getsizeof(lst)}")
# len=0, size=56
# len=10, size=184 ← 扩容了
# len=20, size=248 ← 扩容了

• list：扩容因子约 1.125x，预分配额外空间以减少频繁 realloc
• dict：使用 sparse table（哈希表），负载因子约 2/3 时扩容

预分配大小可以避免反复扩容：

# 如果知道最终大小，预分配避免多次扩容
lst = [0] * 10000 # 一次分配到位

6.4 字符串驻留

sys.intern() 将字符串放入全局驻留表，相同内容的字符串共享同一对象：

import sys

# 场景：大量重复字符串
words = ["error", "warning", "info"] * 10000 # 30000 个字符串对象

# 优化：驻留后共享
words = [sys.intern(w) for w in ["error", "warning", "info"] * 10000]
# 只有 3 个字符串对象，其余都是引用

Python 自动驻留标识符（变量名、函数名、属性名），但对数据字符串需要手动驻留。

6.5 生成器替代列表

列表推导会一次性在内存中创建全部元素。当数据量很大时，峰值内存可能成为瓶颈：

# 列表推导：一次性创建 1000 万个 int 对象（~280MB）
nums = [i for i in range(10_000_000)]

# 生成器表达式：不创建任何元素，仅返回一个生成器对象（~56B）
nums_gen = (i for i in range(10_000_000))

import sys
print(sys.getsizeof(nums)) # ~89MB（列表结构 + 指针数组）
print(sys.getsizeof(nums_gen)) # ~56B（生成器对象本身）

生成器是惰性求值的——只有在迭代时才逐个产出值，产出一个、丢弃一个，不持有历史数据。类比 Java 的 Stream：list.stream() 返回的流不会一次性加载全部元素，range(10_000_000) 类似 IntStream.range(0, 10_000_000)。

生成器函数使用 yield 可以实现惰性管道处理：

def read_large_file(path):
"""逐行读取大文件，不一次性加载到内存"""
with open(path, 'r') as f:
for line in f: # 文件对象本身也是迭代器
yield line.strip()

def filter_lines(lines):
for line in lines:
if line:
yield line

# 管道：每个阶段都是惰性的，内存中同时只有一行
for line in filter_lines(read_large_file("huge.log")):
process(line)

适用场景：大文件逐行处理、无限序列（itertools.count）、管道式数据转换。注意事项：生成器是一次性消费的（不能 len()、不能索引、不能重复迭代），需要多次遍历时先转为 list。

6.6 array.array / numpy

Python list 存储数值时，每个元素都是独立的 PyObject（int 28B），存储 100 万个整数需要 ~28MB 的 Python 对象 + ~8MB 的指针数组 = ~36MB。而 array.array 使用 C 类型数组，每个元素只占 4 字节：

import sys
from array import array

n = 1_000_000

# list：每个 int 28B + 指针 8B ≈ 36MB
lst = list(range(n))
print(sys.getsizeof(lst)) # 8MB（指针数组），实际 + 28MB int 对象

# array.array('i')：每个元素 4B，总计 ~4MB
arr = array('i', range(n))
print(sys.getsizeof(arr)) # ~4MB（紧凑 C 数组，无额外对象开销）

array.array 的类型码决定了元素类型和大小：

对于科学计算或大规模数值处理，numpy 是数值计算的事实标准（第三方库，需 pip install numpy）：

import numpy as np

# numpy 数组：紧凑存储 + 向量化运算
arr = np.arange(10_000_000, dtype=np.int32) # ~40MB，支持 arr * 2 等向量化操作

numpy 额外优势：向量化运算（C 级别循环，比 Python for 快数十倍）、多维数组、丰富的数学函数。但它是第三方依赖，简单场景用 array.array 足够。

选型建议：

小数据（< 1万） → list（简单直接，内存差异可忽略）
中等数据（1万-100万） → array.array（标准库，无额外依赖）
大数据/科学计算 → numpy（向量化运算 + 生态）

七、观测与排查

7.1 监控指标

prometheus_client 自带 ProcessCollector 和 GCCollector，自动暴露：

from prometheus_client import start_http_server

start_http_server(8000) # /metrics 自动包含进程内存指标

宏观监控使用 psutil：

import psutil
import os

def monitor_memory():
process = psutil.Process(os.getpid())
rss = process.memory_info().rss / 1024 / 1024
print(f"RSS: {rss:.2f} MB")

7.2 逐行分析：memory_profiler

from memory_profiler import profile

@profile
def my_function():
a = [1] * (10 ** 6) # ~8MB
b = [2] * (2 * 10 ** 7) # ~160MB
del b
return a

运行：python -m memory_profiler script.py

7.3 sys.getsizeof 的陷阱

sys.getsizeof 只返回对象本身的大小，不包含引用对象：

import sys

data = [1, 2, 3]
print(sys.getsizeof(data)) # 88 bytes（只有列表结构本身）
# 实际占用 = 88 + 3 × 28 = 172 bytes（每个 int 对象 28 bytes）

需要递归计算时，使用 pympler.asizeof：

from pympler import asizeof

print(asizeof.asizeof(data)) # 包含所有引用对象

7.4 泄漏分析工具

tracemalloc：内置轻量分析

import tracemalloc

tracemalloc.start(25) # 记录 25 层调用栈
snapshot_before = tracemalloc.take_snapshot()

# … 执行可疑代码 …
import gc
gc.collect()

snapshot_after = tracemalloc.take_snapshot()
top_stats = snapshot_after.compare_to(snapshot_before, 'lineno')

for stat in top_stats[:10]:
print(stat)

保存快照供离线分析：

snapshot.dump("memory_snapshot.dump")
# 在另一台机器上加载分析
snapshot = tracemalloc.Snapshot.load("memory_snapshot.dump")

tracemalloc 会显著增加内存（官方数据：可能达到 3-4 倍），生产环境建议通过动态开关控制。

memray：生产级推荐（Bloomberg 开源）

memray 是目前 Python 生态最强的内存分析工具，支持 attach 到运行中的进程。

pip install memray

生产环境 attach 模式（推荐）：

# 1. 进入容器
kubectl exec -it <pod-name> — /bin/bash

# 2. 找到进程 PID
ps aux | grep uvicorn

# 3. 附着录制（按需开启，Ctrl+C 停止）
memray attach <PID> -o /tmp/memray-output.bin

# 4. 拷贝到本地离线分析
kubectl cp <pod-name>:/tmp/memray-output.bin ./

# 5. 生成火焰图
memray flamegraph memray-output.bin -o report.html

已知问题：

• 仅支持 Linux/macOS（不支持 Windows）
• –native 模式在旧版本（1.13.0）可能卡死，请升级到 1.13.1+
• Native 模式文件可达 GB 级别，慎用
• 时间轴视图只记录前 100 秒的数据

与 Java 工具对比

核心差异：Java 是"事后 dump"（jmap 随时可 dump），Python 是"事前追踪"（需要提前 tracemalloc.start()）。因此生产环境的最佳实践是服务启动时可选开启追踪 + memray 按需 attach。