Zig 内存管理:显式分配器模式

June 24, 2026 编程学习 Zig, 内存管理, 分配器, Go, Rust, 学习笔记 Zig 语言学习系列 2680 字 6 分钟阅读

本文基于 Zig 0.16。

前几篇我们走过了 Zig 的基础语法和错误处理。现在进入 Zig 最与众不同的部分——内存管理。

如果你有 Go 或 Rust 背景，Zig 的内存哲学会让你感到陌生：它既不提供垃圾回收，也不引入所有权系统，而是选择了一条完全不同的路——分配器模式（Allocator Pattern）。这个模式的核心约定极其简单，但影响深远：

任何可能分配内存的函数，都必须接受一个 std.mem.Allocator 参数。

没有例外，没有隐藏的 malloc，没有隐式的 GC 分配。你看到的就是将要发生的。

三语言内存哲学速览

语言	管理方式	典型开销	开发者控制力
Go	垃圾回收（GC）	GC 停顿、内存占用翻倍	低——调 GC 参数是门玄学
Rust	所有权 + 借用检查 + Drop	编译期检查（运行时零成本）	中——所有权规则有时迫使你重写数据结构
Zig	手动管理 + 分配器模式	完全由你控制	高——每个分配都是显式选择

分配器模式

Zig 的标准库定义了一个 std.mem.Allocator 接口类型（本质上是方法表指针 + 上下文的双指针结构），所有分配器都遵循这个接口。这是 Zig 中最重要的抽象之一。

最基本的用法如下：

zig
1
2
3
4
5
6
7
8
const std = @import("std");

pub fn main() !void {
    const allocator = std.heap.page_allocator;
    const buffer = try allocator.alloc(u8, 100);
    defer allocator.free(buffer);
    @memset(buffer, 0);
}

这里 std.heap.page_allocator 是一个全局的 Allocator 值（不是类型，不需要调用 .init()），它直接向操作系统申请内存页。这种方式最简单，但每次分配都是一次系统调用。

核心 API：

方法	作用	对应其他语言
`allocator.alloc(T, n)`	分配 `n` 个 `T` 类型的连续空间，返回 `[]T`	Go: `make([]T, n)`、Rust: `vec![T; n]`
`allocator.free(slice)`	释放之前分配的切片	Go: GC 自动、Rust: Drop 自动
`allocator.create(T)`	分配单个 `T` 实例，返回 `*T`	Go: `&T{}`、Rust: `Box::new(T)`
`allocator.destroy(ptr)`	释放 `create` 分配的实例	—

注意 alloc/free 和 create/destroy 是成对使用的，混用会导致未定义行为。

`defer` 与资源管理

上面代码中的 defer allocator.free(buffer) 是关键模式——defer 确保释放无论函数在何处返回都会执行。这在 Zig 中替代了 Go 的 GC 和 Rust 的 Drop trait，成为手动内存管理的主力工具。

zig
1
2
3
4
5
6
7
8
9
fn example(allocator: std.mem.Allocator) !void {
    const a = try allocator.alloc(u8, 10);
    defer allocator.free(a);

    const b = try allocator.alloc(u8, 20);
    defer allocator.free(b);

    // 函数退出时，b 先释放，a 后释放（defer 逆序执行）
}

Go 开发者注意： Go 中 make([]byte, 100) 背后是 GC 管理的堆分配，你不需要也不能手动控制释放。Zig 中每个 alloc 必须对应一个 free。写 Zig 的第一习惯：分配之后立刻写 defer。

Rust 开发者注意： Rust 的 Box::new 和 Vec::push 使用全局分配器，你无法在不改全局设置的情况下切换分配策略。Zig 的分配器是作为参数传递的——你可以为不同模块甚至不同对象使用不同的分配器。

常用分配器

Zig 标准库为不同的场景提供了多种分配器。核心原则是：没有万能的分配器，只有最适合场景的分配器。

`page_allocator`

直接向操作系统申请内存页。不需要初始化，全局值直接使用。由于每次分配和释放都涉及系统调用，适合低频大块分配，不适合高频小对象场景。

zig
1
const allocator = std.heap.page_allocator;

`ArenaAllocator`

竞技场分配器——一次创建，批量分配，最后一次性释放所有内存。是 Zig 中最具特色的分配器之一：

zig
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
fn processLotsOfData(allocator: std.mem.Allocator) !void {
    var arena = std.heap.ArenaAllocator.init(allocator);
    defer arena.deinit();

    const arena_allocator = arena.allocator();

    for (0..1000) |_| {
        const item = try arena_allocator.create(i32);
        item.* = 42;
    }
    // 不需要逐个 free，arena.deinit() 会一次性释放全部
}

Arena 的公开 API 在 Zig 0.16 保持不变：

.init(child) — 传入一个后备分配器（通常是 page_allocator 或调试分配器）
.allocator() — 返回一个 Allocator 实例，后续分配通过它完成
.deinit() — 一次性释放所有通过该 arena 分配的内存

不需要逐个 free 每个元素——arena.deinit() 会归还所有内存。这在处理批量数据（如解析请求、处理大量临时对象）时效率极高。

Zig 0.16 重要改进： ArenaAllocator 的内部实现已改为无锁且线程安全。这意味着多个线程可以共享同一个 arena 进行分配，无需额外加锁。在 0.16 之前，需要在 arena 外套一层 std.heap.ThreadSafeAllocator 才能多线程使用——而这个包装器在 0.16 已被移除，因为 ArenaAllocator 等自身已实现线程安全。

`FixedBufferAllocator`

在预先提供的固定字节切片上进行分配——没有堆分配。适合确定最大内存需求的场景（嵌入式系统、中断处理、或任何不允许堆分配的环境）。分配超出缓冲区容量时返回 error.OutOfMemory。

调试分配器

Zig 标准库提供 DebugAllocator 用于开发阶段：它会检测内存泄漏、双重释放、越界写入等常见错误。在单元测试中，std.testing.allocator 是对应的测试分配器，自动在测试报告中标明泄漏位置。

旧版标准库中有一个名为 GeneralPurposeAllocator 的通用分配器。Zig 0.16 中，调试用的分配器以 DebugAllocator 形式提供，带泄漏检测功能，具体 API 以当前标准库文档为准。

分配器选择速查

分配器	适用场景	堆分配	性能特征	线程安全
`page_allocator`	原型、低频大块	是（系统调用）	最慢	是
`ArenaAllocator`	批量临时对象	视后备分配器而定	极快（批量释放）	是（0.16+ 无锁）
`FixedBufferAllocator`	嵌入式、确定大小	否	最快	否（单线程）
`DebugAllocator`	开发调试	是	慢（带检查）	取决于实现
`std.testing.allocator`	单元测试	是	慢（泄漏检测）	—

三语言对比

维度	Go	Rust	Zig
分配方式	`new` / `make` 隐式分配	`Box::new`、`Vec::new` 等	显式 `allocator.alloc` / `allocator.create`
释放方式	GC 自动回收	Drop trait 自动释放	手动 `allocator.free` + `defer`
分配器定制	不可定制	`#[global_allocator]` 全局设置	每个分配作为参数传递
内存安全	GC 保障释放、不保障泄漏	借用检查器编译期保证	开发者负责（调试分配器辅助检测）
典型误区	忘记 `*` 造成拷贝	引用的生命周期标注	忘记 `defer allocator.free` 导致泄漏
分配策略切换	无法切换	全局切换	调用者决定

Go 开发者特别提示

在 Go 中，你几乎从不考虑"使用哪个分配器"——GC 替你打理一切。在 Zig 中，每个分配都是一次明确的选择。最初会觉得麻烦，但很快会发现这种显式性带来的好处：

你能准确知道代码在何时、何地分配内存
你可以为不同的模块使用不同的分配策略
实时系统可以用 FixedBufferAllocator 确保零堆分配
批处理场景用 ArenaAllocator 彻底消除逐个释放的开销
没有 GC 意味着没有 STW 停顿，延迟可预测

Rust 开发者特别提示

Rust 的所有权系统让你不需要手动 free，但全局分配器意味着切换分配策略不是调用方的事。Zig 通过"分配器作为参数"的模式，将分配策略的选择权交给了调用者——一个库函数不会强加分配器选择，传什么就用什么。

Zig 在编译期也没有借用检查器——没有与借用检查器"搏斗"的经历。代价是：你必须自己保证没有 use-after-free 和 double-free。调试分配器在这时就是你最好的朋友。

总结

Zig 的内存管理哲学可以用一句话概括：没有隐式分配，没有隐式释放，一切都在类型系统中显式可见。

关键要点回顾：

“任何可能分配的函数都必须接受 Allocator 参数”——这是 Zig 最具标志性的约定，也是它区别于 Go 和 Rust 的核心设计决策
page_allocator 是最简单的分配器，全局值直接使用，无需初始化
ArenaAllocator 适合批量分配 + 一次性释放，0.16 起内部已无锁且线程安全，不再需要 ThreadSafeAllocator 包装
FixedBufferAllocator 提供零堆分配的保证，适合确定性内存场景
调试分配器开发阶段始终使用，可以捕获泄漏和越界
分配即参数的模式让 Zig 代码在不同场景间切换分配策略变得极其自然

下一篇进入 Zig 最强大的特性——Comptime，编译期计算。你将看到 Zig 如何让编译期与运行时使用完全相同的语法，并以此实现泛型、反射乃至领域特定语言。

所属系列: Zig 语言学习系列

← 上一篇错误处理:Go、Rust 之外的第三条路下一篇 → 结构体与 comptime：编译期计算的威力