知识花园

最近更新

内存管理

21分钟阅读

内存是有限的物理资源。有限就意味着必须归还——用完的内存如果不释放，程序最终会耗尽所有可用空间。但「归还」不是自动发生的，需要有人决定：什么时候归还？如何判断一块内存已经不再需要？

谁来决定归还的时机，就是内存管理哲学的全部。这个问题承接了01-类型系统归属一节的哲学框架——那里提出了三种立场，这里把它们落到具体的机制上。

一、物理现实：为什么管理是个问题

在讨论「谁负责归还」之前，先理解「归还什么」——内存在物理上有两种完全不同的存在形式。

栈与堆：两种生命周期形状

栈分配（Stack） 是自动管理的。每次函数调用时，局部变量和参数被压入栈帧；函数返回时，整个栈帧被弹出。栈指针的移动是一条 CPU 指令，分配几乎零成本。生命周期在编译时就已确定——函数结束，资源消亡，天然 LIFO。

堆分配（Heap） 是灵活的。你可以在运行时请求任意大小的内存，生命周期不受函数栈帧限制。但分配器需要搜索空闲块、维护元数据、处理碎片——比栈分配慢 10-100 倍。灵活性的代价是：没有人能在编译时知道什么时候该释放它。

这正是内存管理问题的根源：栈上的内存天然知道何时结束，堆上的内存不知道。所有内存管理策略，本质上都是在回答「堆内存何时可以归还」这个问题。

什么时候必须用堆：对象大小运行时才确定、生命周期需要跨越函数边界、数据需要在多处共享。

内存层级：无法忽视的物理约束

CPU 的速度远超内存访问速度，现代处理器用多级缓存弥合这一鸿沟：

层级典型大小访问延迟相对速度
L1 缓存32-64 KB~1 ns1x（基准）
L2 缓存256 KB-1 MB~4 ns4x
L3 缓存4-32 MB~12 ns12x
主内存（DRAM）数 GB~100 ns100x

缓存行（Cache Line） 是缓存与主内存之间数据传输的最小单位，通常 64 字节。访问一个字节，整个缓存行都会被加载——这意味着访问相邻内存几乎免费，访问随机地址代价高昂。

伪共享（False Sharing） 是多线程编程中的隐蔽陷阱：两个线程分别写入不同变量，但这两个变量恰好在同一个缓存行中——CPU 核心之间会不断使对方的缓存行失效，性能暴跌。

这是物理约束，不是设计选择。所有语言的内存管理策略都必须在这个约束下运作，只是不同语言让程序员暴露在不同程度的约束细节面前。

二、三种哲学答案

物理现实是共同的起点，但「谁来决定归还」这个问题，有三种根本不同的回答。

答案一：程序员负责（手动管理）

哲学立场：个体主义——你申请的内存，你来决定何时归还。C 是这种立场最彻底的代表。

char* buffer = malloc(1024);   // 申请
// ... 使用 ...
free(buffer);                  // 归还：程序员决定这一刻
buffer = NULL;                 // 防止悬垂指针，但需要纪律

完全的控制权带来完全的责任。当程序员判断失误时，会产生四类内存安全错误：

  • Use-After-Free（UAF）：内存释放后继续使用指向它的指针。最常见的安全漏洞来源，可能导致任意代码执行
  • Double-Free：对同一块内存调用两次 free，破坏分配器内部结构
  • Buffer Overflow：写入超过缓冲区边界，覆盖相邻数据
  • Null Dereference：解引用空指针，通常导致程序崩溃

这些错误在 C/C++ 中是未定义行为（undefined behavior）——程序不一定立刻崩溃，可能悄悄产生错误结果，也可能被攻击者利用。长期以来，内存安全漏洞占 CVE 数据库中高危漏洞的 60-70%。

代价总结：零运行时开销、完全可预测，但心智负担极高，错误代价致命。

答案二：运行时负责（GC）

哲学立场：集体主义——专门的运行时组件（垃圾回收器）追踪所有内存的使用状态，统一决定何时归还。程序员不需要、也不应该手动释放内存。

def process():
    data = load_large_dataset()   # 在堆上分配
    result = transform(data)
    return result
    # data 不再被引用，GC 会在某个时机回收它
    # 程序员不需要、也没有办法决定具体时机

GC 并非单一算法，而是一个算法家族——每种算法在「暂停时间 / 吞吐量 / 内存占用」三者之间做出不同权衡：

graph TD
    A["垃圾回收算法"] --> B["追踪式 (Tracing)"]
    A --> C["引用计数 (Reference Counting)"]
    
    B --> B1["标记-清除 (Mark-Sweep)"]
    B --> B2["复制 (Copying)"]
    B --> B3["标记-整理 (Mark-Compact)"]
    B --> B4["分代 (Generational)"]
    
    B4 --> B5["增量 (Incremental)"]
    B4 --> B6["并发 (Concurrent)"]
    
    B1 -->|"碎片问题"| D["需要整理"]
    B2 -->|"无碎片"| E["空间减半"]
    B4 -->|"利用弱分代假设"| F["主流策略"]
    
    C --> C1["即时释放"]
    C --> C2["循环引用问题"]
    
    style A fill:#4dabf7,color:#fff
    style F fill:#69db7c,color:#fff
    style C2 fill:#ff6b6b,color:#fff

标记 - 清除（Mark-Sweep）：从根集合出发遍历所有可达对象并标记，然后清除未标记的对象。实现简单，但会产生内存碎片，暂停时间与堆大小成正比。

复制（Copying）：将堆分为两个半空间，GC 时把存活对象全部复制到另一侧，交换角色。完全没有碎片，分配只需移动指针；缺点是浪费一半内存空间。新生代 GC 常用此算法——新生代存活率低，复制成本可控。

标记 - 整理（Mark-Compact）：先标记，然后将存活对象向一端移动，消除碎片，同时不浪费空间。移动成本较高，需要更新所有指向被移动对象的指针。老年代 GC 常用此算法。

分代 GC（Generational）：基于「大多数对象朝生夕死」的弱分代假设，将堆分为多个代——年轻代频繁回收（存活率低，成本低），老年代较少回收。这是现代 GC 的基础架构，大幅减少需要扫描的对象数量。

增量与并发 GC：增量 GC 将工作拆成小步穿插执行，避免长时间暂停；并发 GC 让 GC 线程与应用线程同时运行。两者都需要写屏障（write barrier） 追踪应用程序对对象图的修改，保证正确性。

三色标记法是并发 GC 的理论基础：白色（未访问）、灰色（已访问但引用未完全处理）、黑色（已完全处理）。正确性条件是：任何时刻，不存在从黑色对象直接指向白色对象的引用，否则该白色对象会被错误回收。

引用计数是另一类策略（CPython 的主策略）：每个对象维护一个被引用次数，计数归零时立即释放。优点是释放时机确定、可以立即回收；致命弱点是无法处理循环引用——CPython 用一个独立的分代 GC 专门处理这个边角情况。

各算法的权衡对比：

算法暂停时间吞吐量内存占用碎片
标记 - 清除长高低有
复制中中高（半空间浪费）无
标记 - 整理长中低无
分代短高中取决于老年代
增量短（但频繁）中低取决于基础算法
并发极短中 - 低中取决于基础算法

V8 的 Orinoco GC 能做到亚毫秒暂停，靠的是：并发标记（后台线程完成主要工作）+ 增量标记（主线程只处理小块）+ 惰性清除（按需而非集中清除）。代价是额外的写屏障开销和更高的内存占用。

代价总结：程序员心智负担低，但 GC 暂停、运行时开销、内存放大（GC 语言通常需要 3-5 倍实际使用量的堆空间才能高效运行）是真实成本。对于高频交易、实时系统，即使 1ms 的 GC 暂停也不可接受。

答案三：类型系统负责（所有权）

哲学立场：合同主义——把「归还」的责任编码进类型系统，让编译器在编译时证明每块内存会被恰好释放一次。不需要运行时 GC，也不依赖程序员自律。

理论基础：仿射类型（Affine Types）。仿射类型要求每个值最多使用一次——可以不用（忽略），但不能在转移后继续使用。Rust 的所有权系统本质上就是仿射类型系统：

let s = String::from("hello");  // s 拥有这块堆内存
let t = s;                       // 所有权转移给 t，s 不再有效
println!("{}", s);               // 编译错误！s 的所有权已转移

值离开作用域时，Drop trait 自动触发释放——确定性的、零运行时开销的资源回收：

{
    let file = File::open("data.txt")?;
    // ... 使用文件 ...
}   // file 离开作用域，Drop 自动关闭文件句柄
    // 不需要 finally，不需要 defer，编译器保证

借用与生命周期 解决了「如何在不转移所有权的情况下使用值」的问题：

fn print_length(s: &String) {   // 借用：只读访问，不获得所有权
    println!("{}", s.len());
}   // 借用结束，所有权还在调用方
 
// 生命周期标注：确保引用不会活得比被引用的值更久
fn longest<'a>(x: &'a str, y: &'a str) -> &'a str {
    if x.len() > y.len() { x } else { y }
}

共享所有权 需要显式选择：Rc<T> 用于单线程引用计数共享，Arc<T> 用于多线程安全共享，Weak<T> 用于打破循环引用。这些都是库类型，不是语言魔法——程序员清楚地知道自己在做什么。

代价总结：零运行时开销、完全确定的释放时机、编译时内存安全保证。代价是学习曲线——理解所有权和借用规则需要时间，但这是一次性投资，之后编译器成为你的安全盟友。

三、物理约束反向影响设计

内存管理不只是「抽象落地」的单向过程——物理约束也在塑造抽象选择。

内存布局决定缓存效率

Python 每个对象有 28-56 字节的对象头（引用计数、类型指针、哈希值），Java 有 12-16 字节。这不是设计疏忽，而是动态类型和 GC 的必然代价：运行时需要元数据来管理对象。

Rust 结构体没有对象头，字段按声明顺序紧凑排列，编译器只做对齐填充：

struct Point { x: f64, y: f64 }
// 内存占用恰好 16 字节，紧凑连续，缓存友好

这不只是「节省内存」——紧凑布局意味着更高的缓存命中率，对性能敏感的代码，这个差距可以是数量级的。

数据导向设计（Data-Oriented Design） 的核心洞察：让数据布局匹配 CPU 的访问模式。

// 面向对象：每个元素是独立对象（指针追逐，缓存不友好）
struct Entity { x: f32, y: f32, health: i32 }
let entities: Vec<Entity> = ...;
 
// 数据导向：按字段组织（连续内存，缓存友好）
struct Entities { xs: Vec<f32>, ys: Vec<f32>, healths: Vec<i32> }

遍历所有实体的 x 坐标时，后者每次都能利用缓存行里的相邻数据；前者每个元素跳跃访问，不断触发缓存缺失。

GC 策略影响内存消耗上限

GC 语言需要额外的内存余量才能高效运行——GC 通常在堆使用达到某个阈值（如 75%）时触发，意味着实际可用内存只有总量的一部分。Go 的目标是将 GC 开销控制在 CPU 时间的 25% 以内，代价是内存占用约为实际存活对象的 2-4 倍。

这解释了为什么内存受限的场景（嵌入式、边缘计算）几乎都用 C 或 Rust——不是因为 GC「不好」，而是因为物理约束不允许额外的内存开销。

四、内存安全的形式化定义

内存安全是一个可以精确定义的概念，不是模糊的「写得小心一点」：

错误类型PythonTypeScriptRust
Use-After-Free不可能（GC 管理）不可能（GC 管理）编译时阻止
Double-Free不可能不可能编译时阻止
Buffer Overflow不可能（运行时边界检查）不可能（运行时边界检查）编译时/运行时阻止
Null Dereference极少（None 有类型保护）极少（undefined 有类型保护）编译时阻止（无 null）

Python 和 TypeScript 通过 GC 和运行时检查消除这些错误，代价是运行时开销。Rust 通过编译时检查消除，代价是学习曲线。C/C++ 不提供任何保证——长期以来内存安全漏洞占高危 CVE 的 60-70%。

五、三语对照：不同哲学的工程落地

维度PythonTypeScript（V8）Rust
归属哲学集体主义（GC）集体主义（GC）合同主义（所有权）
回收策略引用计数 + 分代 GC标记 - 清除 + 分代 + 增量并发编译时所有权 + 借用检查
运行时开销计数操作 + GC 暂停GC 暂停（高度优化）零运行时开销
循环引用分代 GC 处理并发标记处理编译约束（Rc/Weak 显式处理）
对象内存占用高（28-56 字节对象头）中（V8 隐藏类优化）最小（无对象头）
确定性释放引用计数提供（非循环时）不保证（GC 周期决定）完全确定（离开作用域）
缓存友好度低（对象分散、指针追逐）中等（隐藏类优化）高（紧凑布局、连续内存）
内存安全保证运行时保证运行时保证编译时保证
适用场景脚本、数据科学、WebWeb、服务端、桌面系统编程、嵌入式、性能敏感

Python：引用计数提供即时释放和确定性（非循环情况下），分代 GC 处理循环引用。代价是每个对象都有额外的元数据开销，以及偶发的 GC 暂停。__slots__ 可以减少 30-50% 的对象内存占用；tracemalloc 用于诊断内存问题。

TypeScript（V8）：Orinoco GC 的目标是亚毫秒暂停——并发标记在后台线程完成，主线程只处理小块增量工作。对开发者基本透明，但内存泄漏（事件监听器未移除、闭包持有大对象）仍需注意。WeakMap / WeakRef 用于避免阻止 GC 回收。

Rust：三种选择中唯一在编译时解决内存安全的。所有权规则在第一次接触时会引发认知冲突，但这是一次性投资——理解之后，编译器会在编译时告诉你所有内存错误，而不是在运行时崩溃。高频交易系统、操作系统内核、嵌入式固件等对延迟和内存使用有严格要求的场景，是 Rust 的天然领域。

三语的内存管理差异，本质上是01-类型系统归属问题的工程落地：Python 和 TypeScript 把责任交给运行时（程序员专注业务逻辑），Rust 把责任编进类型（编译器成为安全的执行者）。没有绝对正确的选择，只有在约束条件下合适的选择。

延伸阅读

关联 meta 维度

  • 01 类型系统 — 内存管理是类型系统「归属」问题的具体实现；所有权类型直接决定内存管理策略
  • 05 并发模型 — 共享内存是并发安全的核心问题；Arc/Mutex 是所有权在并发场景的延伸
  • 07 编译与执行 — GC 是运行时机制，所有权是编译时机制；两者代表不同的执行时权衡

关系图谱

反向链接