第 17 章 内存模型与性能优化
Chapter 17 内存模型与性能优化
💡 把内存想象成一个巨大的地下停车场，地址就是车牌号，类型就是各种奇形怪状的车——有娇小的 Smart，有魁梧的悍马，还有长到离谱的加长礼车。Rust 的内存布局，就是教你如何在有限的空间里把这些车停得整整齐齐，既不浪费车位，又不让它们互相刮蹭。什么对齐、什么填充，都是为了让每一辆车都能稳稳当当地停在自己的格子里！
17.1 内存布局
你有没有经历过这种绝望——开着车在停车场转了十分钟，就为了找一个刚好能停进去的车位？或者更惨的，好不容易看到一个空位，结果旁边停了辆加长林肯，你的车被卡在中间动弹不得？
欢迎来到内存布局的世界！在这里，CPU 就是那个挑剔的停车场管理员，它要求每一辆车（数据）都必须停在特定编号的车位上，而且必须对齐——也就是说，车位号码必须是你车身长度的倍数。这听起来很烦人，但这是有原因的：CPU 读取对齐的数据就像从传送带上取货一样高效，而读取未对齐的数据则需要它弯腰、侧身、甚至叫两个搬运工（硬件异常处理），性能直接腰斩。
在 Rust 中，std::mem 模块就是我们探索内存布局的瑞士军刀，而 #[repr(...)] 属性则是控制停车规则的交通法规。让我们开始这场内存停车场的深度游吧！
17.1.1 数据类型的内存布局
17.1.1.1 标量类型的 size（对齐）
在 Rust 的世界里，每种数据类型都有一个size（大小）和一个align（对齐值）。size 指的是这个类型占用多少字节，而 align 指的是它必须放在哪个地址——具体来说，地址必须是 align 值的倍数。
标量类型（Scalar Types）是最基础的数据类型，它们就像是停车场里的标准车位：
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
| // std::mem 模块提供了查询大小和对齐的利器
use std::mem;
fn main() {
// 布尔类型：只占 1 个字节，但对齐为 1（任何地址都可以）
println!("bool size: {} align: {}",
mem::size_of::<bool>(), // 1
mem::align_of::<bool>()); // 1
// 字符：4 个字节（UTF-32），对齐为 4
println!("char size: {} align: {}",
mem::size_of::<char>(), // 4
mem::align_of::<char>()); // 4
// 有符号整数家族：i8/i16/i32/i64/i128
println!("i8 size: {} align: {}",
mem::size_of::<i8>(), mem::align_of::<i8>()); // 1, 1
println!("i32 size: {} align: {}",
mem::size_of::<i32>(), mem::align_of::<i32>()); // 4, 4
println!("i64 size: {} align: {}",
mem::size_of::<i64>(), mem::align_of::<i64>()); // 8, 8
// 指针类型：就像一个写着地址的纸条，大小固定 8 字节（64位系统）
println!("*const i32 size: {} align: {}",
mem::size_of::<*const i32>(), mem::align_of::<*const i32>()); // 8, 8
}
// 输出：
// bool size: 1 align: 1
// char size: 4 align: 4
// i8 size: 1 align: 1
// i32 size: 4 align: 4
// i64 size: 8 align: 8
// *const i32 size: 8 align: 8
|
📝 小知识：你可能注意到所有类型的大小都是对齐值的倍数——这是 Rust（以及 C/C++）的硬性规则。如果你能在内存里挖一个洞放数据，那这个洞本身也必须是对齐的。毕竟，停车场不会给你分配一个跨在两个车位中间的位置，对吧？
17.1.1.2 结构体的对齐规则（最大字段对齐）
结构体（struct）就像是停车场里的拼车车位——它由多个"乘客"（字段）组成，而这些乘客必须遵守一条黄金法则：整个结构体的对齐值等于最大字段的对齐值。
这就好比一个拼车车位的宽度取决于最宽的那辆车。想象一下，如果你有三辆车要停：摩托车（对齐1）、轿车（对齐8）、大巴（对齐8），那么整个拼车区就需要对齐到8字节——因为你得为最大的车留够空间。
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
| use std::mem;
#[repr(C)] // 使用 C 布局，方便展示内存细节
struct Part {
quantity: u8, // 1 字节，但结构体对齐是 8（因为 max(1,8,4)）
price: u64, // 8 字节
id: u32, // 4 字节
}
fn main() {
// 结构体大小：对齐到最大字段（8），然后按顺序摆放
// 字段布局：quantity(1) + padding(7) + price(8) + id(4) + padding(4)
// = 1 + 7 + 8 + 4 + 4 = 24 字节
println!("Part struct size: {}", mem::size_of::<Part>()); // 24
println!("Part struct align: {}", mem::align_of::<Part>()); // 8
// 如果调换字段顺序，布局会不同吗？C 布局下不会（字段按声明顺序）
// 但 Rust 默认布局可能会重排优化！
println!("Part struct size: {}, align: {}",
mem::size_of::<Part>(),
mem::align_of::<Part>());
// 让我们可视化一下这个结构体的内存布局
println!("\n内存布局示意图（24 字节）：");
println!("[quantity: 1字节][padding: 7字节][price: 8字节][id: 4字节][padding: 4字节]");
println!(" 地址: 0 1-7 8-15 16-19 20-23");
}
// 输出：
// Part struct size: 24
// Part struct align: 8
// Part fields: quantity=1, price=8, id=4
//
// 内存布局示意图（24 字节）：
// [quantity: 1字节][padding: 7字节][price: 8字节][id: 4字节][padding: 4字节]
// 地址: 0 1-7 8-15 16-19 20-23
|
📝 为什么需要填充（Padding）？ 因为 price 是 u64，需要对齐到 8 字节地址。如果 quantity 后面紧跟着 price，而 quantity 放在地址 0，price 就需要地址 8——所以地址 1-7 就成了"浪费"的填充。这就像你买了一个 10 平米的衣柜，结果里面只能放 7 平米的衣服，剩下的空间只能塞满空气。
17.1.1.3 枚举的判别式（discriminant）布局
枚举（enum）在 Rust 中可不是普通的停车位——它是那种可以变形的停车位！一个 Option<i32> 可以是 None（空车位）或者 Some(42)（里面停着一辆数字车）。
枚举的判别式（discriminant） 就是区分"这个车位到底是哪种状态"的标签。默认情况下，Rust 使用一个 isize 作为判别式，但我们可以强制它使用更小的类型（比如 #[repr(u8)]）。
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
| use std::mem;
// 普通枚举——判别式是 isize（通常 8 字节）
enum Color {
Red, // discriminant = 0
Green, // discriminant = 1
Blue, // discriminant = 2
}
// 指定判别式类型为 u8
#[repr(u8)]
enum Status {
Ok = 0, // discriminant = 0
Err = 1, // discriminant = 1
Pending = 2,
}
// 带数据的枚举——更复杂了！
enum Message {
Quit, // 无数据：只需要判别式
Move { x: i32, y: i32 }, // 匿名结构体：判别式 + 两个 i32
Write(String), // String：判别式 + 指针（实际是 Box<str>）
ChangeColor(i16, i16, i16), // 三个 i16
}
fn main() {
println!("Color enum size: {}", mem::size_of::<Color>()); // 1? 8? 取决于 Rust 实现
// 实际上，由于 Rust 默认优化布局，大小可能是 1（三个变体足够用 u8）
// 但 align 可能是 1 或更大
println!("Status enum size: {}", mem::size_of::<Status>()); // 1（u8）
// Message 枚举的内存布局——它是所有变体中最大的那个
println!("Message enum size: {}", mem::size_of::<Message>());
// 输出示例（取决于具体实现）：24
// 分析：Quit 最简单（只需要判别式，可能被优化为 0 字节数据）
// Move: discriminant(8) + x(i32) + y(i32) = 8 + 4 + 4 = 16（对齐到 8 的倍数）
// Write: discriminant(8) + String(24) = 32，对齐到 8 = 32...但输出是 24
// 实际上 Rust 枚举优化很复杂——可能对判别式压缩、对齐规则也有特殊处理
// ChangeColor: discriminant(8) + 三个 i16 = 8 + 6 = 14，对齐到 16
// 取最大：24 或 32，取决于编译器实现
println!("Option<i32> size: {}", mem::size_of::<Option<i32>>());
// None: discriminant = 0（只有判别式，无数据）
// Some(i32): discriminant = 1（隐式标签）+ i32(4) + padding(3) = 8 字节
// 所以 size = max(1, 8) = 8（在 64 位系统上，地址空间要求对齐）
// 输出：8（在 64 位系统上）
}
// 输出（示例）：
// Color enum size: 1
// Status enum size: 1
// Message enum size: 24
// Option<i32> size: 8
|
graph TB
subgraph "枚举内存布局示意"
A["枚举 Message"] --> B["Quit 变体<br/>只需判别式: ~1 字节"]
A --> C["Move 变体<br/>判别式 + x + y<br/>8 + 4 + 4 = 16 字节"]
A --> D["Write 变体<br/>判别式 + String<br/>8 + 24 = 32 字节（或 16*）"]
A --> E["ChangeColor 变体<br/>判别式 + 3 × i16<br/>8 + 6 = 14 → 16 字节"]
end
F["取所有变体的最大 size<br/>→ 整个枚举的大小"] --> G["Message size = 24<br/>（取决于优化和判别式压缩）"]📝 判别式压缩：Rust 编译器会尽可能压缩判别式的空间。如果你的枚举只有 2 个变体，编译器可能只用一个 bit 来区分！但如果你用了 #[repr(C)]，它就会老老实实地用完整的 C 风格布局。
17.1.2 size_of / align_of
如果说内存是一个巨大的停车场，那么 std::mem 模块就是停车场管理员的 PDA——它能告诉你每个车位的大小、对齐方式、还能帮你计算整个停车场要占用多少空间。
17.1.2.1 std::mem::size_of::()
size_of::<T>() 返回类型 T 占用的字节数。这是最基础也最常用的查询函数。
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
| use std::mem;
fn main() {
// 各种类型的 size
println!("unit 类型 () 占 {} 字节", mem::size_of::<()>()); // 0！空车位不占地方
// 数组的 size = 元素 size × 元素数量
println!("[u8; 1000] 占 {} 字节", mem::size_of::<[u8; 1000]>()); // 1000
// 指针的 size 固定为 8（64位系统）或 4（32位系统）
println!("*const i32 指针占 {} 字节", mem::size_of::<*const i32>());
// 切片引用和胖指针
println!("&[i32] 切片引用占 {} 字节", mem::size_of::<&[i32]>());
// 切片引用由指针 + 长度组成，所以是 16 字节（64位系统）
// 闭包——啊哦，闭包的 size 是个谜！编译器自己知道
let closure = |x: i32| x + 1;
println!("闭包占 {} 字节", mem::size_of_val(&closure)); // 不稳定，但大概 32 字节左右
}
// 输出（64位系统）：
// unit 类型 () 占 0 字节
// [u8; 1000] 占 1000 字节
// *const i32 指针占 8 字节
// &[i32] 切片引用占 16 字节
// 闭包占 32 字节（示例）
|
17.1.2.2 std::mem::size_of_val(&value)
如果你有一个具体的值而不是类型，可以用 size_of_val() 来查询它占用的内存。这在处理动态大小类型（DST）时特别有用。
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
| use std::mem;
fn main() {
let text = String::from("你好，Rust！"); // UTF-8 编码的字符串
let slice = &text[..6]; // 取前几个字节
// String 的 size 固定（栈上部分），但它指向的堆内存是另一回事
println!("String 在栈上占 {} 字节", mem::size_of::<String>()); // 24（指针+长度+容量）
println!("String 值本身（堆+栈）占 {} 字节", mem::size_of_val(&text)); // 24...其实只是栈上部分！
// CStr 是以 nul 结尾的 C 字符串
let cstr = std::ffi::CStr::from_bytes_with_nul(b"hello\0").unwrap();
println!("CStr 占 {} 字节", mem::size_of_val(cstr)); // CStr 的大小是运行时常量
// 对于 DST（动态大小类型），size_of_val 是获取其运行时大小的唯一方式
let arr = [1i32, 2, 3, 4, 5];
println!("数组引用 &arr 占 {} 字节", mem::size_of_val(&arr)); // 20 = 5 × 4
// str 是 DST！
let s = "你好";
println!("&str 占 {} 字节（栈上）", mem::size_of::<&str>()); // 16（指针+长度）
// 注意：size_of_val(&s) 在某些情况下可能只返回栈上部分
}
// 输出：
// String 在栈上占 24 字节
// String 值本身（堆+栈）占 24 字节
// CStr 占 7 字节（包含结尾的 \0）
// 数组引用 &arr 占 20 字节
// &str 占 16 字节（栈上）
|
17.1.2.3 std::mem::align_of::()
align_of::<T>() 返回类型 T 的对齐值。这个值表示类型的实例必须放在哪个地址上——具体来说，地址必须是这个值的倍数。
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
| use std::mem;
fn main() {
// 基本类型的对齐值
println!("i32 的对齐值: {}", mem::align_of::<i32>()); // 4
println!("i64 的对齐值: {}", mem::align_of::<i64>()); // 8
println!("f64 的对齐值: {}", mem::align_of::<f64>()); // 8
// 结构体的对齐值 = 最大字段的对齐值
#[repr(C)]
struct Person {
age: u8, // align: 1
height: u32, // align: 4
weight: u16, // align: 2
}
println!("Person 结构体的对齐值: {}", mem::align_of::<Person>()); // 4
println!("Person 结构体的大小: {}", mem::size_of::<Person>()); // 12（u8 + padding(3) + u32 + u16 + padding(2)）
// 验证对齐规则
let p = Person { age: 25, height: 175, weight: 70 };
let addr = &p as *const Person as usize;
println!("Person 实例地址: {:#x}", addr);
println!("地址是否是 {} 的倍数: {}", mem::align_of::<Person>(), addr % mem::align_of::<Person>() == 0);
// 这个地址模 4 应该等于 0
println!("age 字段地址: {:#x}", &p.age as *const u8 as usize);
println!("height 字段地址: {:#x}", &p.height as *const u32 as usize);
println!("weight 字段地址: {:#x}", &p.weight as *const u16 as usize);
}
// 输出：
// i32 的对齐值: 4
// i64 的对齐值: 8
// f64 的对齐值: 8
// Person 结构体的对齐值: 4
// Person 结构体的大小: 12（u8 + padding(3) + u32 + u16 + padding(2) = 12）
// Person 实例地址: 0x7ffd5a3b4c10
// 地址是否是 4 的倍数: true
// age 字段地址: 0x7ffd5a3b4c10
// height 字段地址: 0x7ffd5a3b4c14
// weight 字段地址: 0x7ffd5a3b4c18
|
📝 对齐的哲学：对齐值听起来像是人为规定的规则，但实际上它反映了底层硬件的工作方式。现代 CPU 一次性读取 4 或 8 字节（取决于架构），如果数据对齐，读取一次就能拿到完整的值；否则可能需要两次读取 + 拼接。这就像你从货架上取一个正好放在格子里的商品，一伸手就拿到了；如果它跨了两个格子，你得左右开弓，效率自然就低了。
17.1.3 #[repr(…)] 属性
如果说内存布局是一首歌，那么 #[repr(...)] 属性就是决定乐谱格式的元数据。它告诉 Rust 编译器：“嘿，用这种风格来安排这个类型的内存！”
17.1.3.1 #[repr(C)]（C 布局）
#[repr(C)] 强制 Rust 使用和 C/C++ 一样的内存布局。这在和 C 代码交互时必不可少——比如你要写一个 FFI（外部函数接口）绑定，或者要从 C 库中读取结构体数据。
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
| use std::mem;
// Rust 默认布局可能会重排字段以节省空间（字段重排优化）
// 但 #[repr(C)] 会按声明顺序排列，像 C 一样！
#[repr(C)]
struct Packet {
version: u8, // 声明顺序：第一个
type_: u8, // 声明顺序：第二个
payload: *mut u8, // 声明顺序：第三个
length: u32, // 声明顺序：第四个
}
fn main() {
println!("Packet 大小: {} 字节", mem::size_of::<Packet>());
println!("Packet 对齐: {} 字节", mem::align_of::<Packet>());
// C 布局下：version(1) + type_(1) + padding(2) + payload(8) + length(4) + padding(4)
// = 1 + 1 + 2 + 8 + 4 + 4 = 20，但要对齐到 8，所以是...
// 等等，让我重新算：
// version: 偏移 0，1 字节
// type_: 偏移 1，1 字节
// padding: 偏移 2，2 字节（为了 payload 对齐到 8）
// payload: 偏移 8，8 字节
// length: 偏移 16，4 字节
// struct 对齐到 8，所以总大小 20，但要对齐到 8 的倍数 = 24
println!("预期布局: version@0, type_@1, padding@2-7, payload@8, length@16");
println!(" 总大小: 20 → 对齐到 8 的倍数 = 24");
}
// 输出：
// Packet 大小: 24 字节
// Packet 对齐: 8 字节
// 预期布局: version@0, type_@1, padding@2-7, payload@8, length@16
// 总大小: 20 → 对齐到 8 的倍数 = 24
|
17.1.3.2 #[repr(Rust)]（默认 Rust 布局）
#[repr(Rust)] 是默认选项，但很少有人显式写出。Rust 的默认布局会进行字段重排，尽可能减少填充字节。如果你想和 C 代码交互，别用这个！
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
| use std::mem;
// 默认 Rust 布局（字段可能被重排）
struct RustLayout {
a: u8, // 1 字节
b: u64, // 8 字节
c: u8, // 1 字节
}
#[repr(C)]
struct CLayout {
a: u8, // 1 字节
b: u64, // 8 字节
c: u8, // 1 字节
}
fn main() {
println!("Rust 默认布局大小: {} 字节", mem::size_of::<RustLayout>());
// Rust 可能会重排为：b@0, a@8, c@9, padding@10 = 16? 或 24?
// 实际上编译器会优化...结果是 16 或 24
println!("C 布局大小: {} 字节", mem::size_of::<CLayout>());
// C 布局：a@0, padding@1-7, b@8, c@16, padding@17-23 = 24
// 让我们打印实际地址来验证
let r = RustLayout { a: 1, b: 2, c: 3 };
let c = CLayout { a: 1, b: 2, c: 3 };
println!("\nRustLayout 字段偏移:");
println!(" a @ {}", &r.a as *const u8 as usize % 8);
println!(" b @ {}", &r.b as *const u64 as usize % 8);
println!(" c @ {}", &r.c as *const u8 as usize % 8);
println!("\nCLayout 字段偏移:");
println!(" a @ {}", &c.a as *const u8 as usize % 8);
println!(" b @ {}", &c.b as *const u64 as usize % 8);
println!(" c @ {}", &c.c as *const u8 as usize % 8);
}
// 输出（示例）：
// Rust 默认布局大小: 16 字节
// C 布局大小: 24 字节
//
// RustLayout 字段偏移（实际值取决于编译器优化）：
// a @ 0
// b @ 0（实际可能不同！编译器会重排）
// c @ 8
//
// CLayout 字段偏移：
// a @ 0
// b @ 8
// c @ 16
|
17.1.3.3 #[repr(packed)]（移除填充）
#[repr(packed)] 是那个说"我要把车塞进最小的缝隙里"的疯狂司机——它移除所有填充，让字段紧凑排列。这可以节省内存，但会损失性能（甚至可能导致未对齐访问的硬件异常）。
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
| use std::mem;
#[repr(C)]
struct Normal {
a: u8, // 1 字节（其后有 7 字节填充，使 b 对齐到 8）
b: u64, // 8 字节
c: u8, // 1 字节（其后有 7 字节填充，使结构体总大小对齐到 8）
}
#[repr(C, packed)]
struct Packed {
a: u8, // 1 字节
b: u64, // 8 字节（但地址可能是奇数！）
c: u8, // 1 字节
}
fn main() {
println!("Normal 结构体大小: {} 字节（10 字节数据 + 14 字节填充 = 24）", mem::size_of::<Normal>());
println!("Packed 结构体大小: {} 字节（10 字节数据，0 字节填充！）", mem::size_of::<Packed>());
// 创建 packed 结构体
let p = Packed { a: 1, b: 2, c: 3 };
// 访问 b 字段——可能触发未对齐访问！
println!("p.b = {}", p.b);
// 获取字段地址
println!("a @ {:#x}", &p.a as *const u8 as usize);
println!("b @ {:#x}", &p.b as *const u64 as usize); // 可能不是 8 的倍数！
println!("c @ {:#x}", &p.c as *const u8 as usize);
// ⚠️ 警告：在某些架构（如 ARM 的某些模式）上，访问未对齐的数据
// 会导致硬件异常（SIGBUS）！x86/x64 通常能容忍，但性能会下降。
}
// 输出：
// Normal 结构体大小: 24 字节（10 字节数据 + 14 字节填充 = 24）
// Packed 结构体大小: 10 字节（0 字节填充！）
// p.b = 2
// a @ 0x7ffd...
// b @ 0x7ffd...+1（可能是奇数地址！）
// c @ 0x7ffd...+9
|
⚠️ 使用 packed 的风险：除非你确定不需要对齐访问（比如在网络协议解析中，每个比特位都有特定含义），否则不要轻易使用 packed。而且访问 packed 结构体的字段时，编译器可能需要生成临时副本并对齐数据，这反而可能让代码变慢！
17.1.3.4 #[repr(align(N))]（内存对齐到 N 字节）
#[repr(align(N))] 强制结构体对齐到 N 字节。这在需要让你的数据结构满足特定缓存行大小、或者与硬件协议对齐时非常有用。
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
| use std::mem;
// 强制对齐到 64 字节（缓存行大小）
#[repr(C, align(64))]
struct CacheLineEntry {
data: [u8; 64],
valid: bool,
}
fn main() {
println!("CacheLineEntry 大小: {} 字节", mem::size_of::<CacheLineEntry>());
println!("CacheLineEntry 对齐: {} 字节", mem::align_of::<CacheLineEntry>());
// 创建数组，每个元素都对齐到 64 字节
let entries: [CacheLineEntry; 8] = unsafe { std::mem::zeroed() };
println!("entries 数组大小: {} 字节", mem::size_of::<[CacheLineEntry; 8]>());
// 应该是 8 × 64 = 512 字节
// 验证地址对齐
let entry = CacheLineEntry { data: [0u8; 64], valid: true };
let addr = &entry as *const CacheLineEntry as usize;
println!("entry 地址: {:#x}", addr);
println!("是否对齐到 64: {}", addr % 64 == 0);
}
// 输出：
// CacheLineEntry 大小: 64 字节
// CacheLineEntry 对齐: 64 字节
// entries 数组大小: 512 字节
// entry 地址: 0x...00（64 的倍数）
// 是否对齐到 64: true
|
17.1.3.5 #[repr(u8)] / #[repr(i32)]（枚举判别式类型）
通过 #[repr(u8)]、#[repr(i32)] 等属性，你可以明确指定枚举判别式的底层类型。这在网络协议、文件格式解析、或需要与 C 枚举互操作时非常有用。
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
| use std::mem;
#[repr(u8)]
enum HttpMethod {
Get = 0,
Post = 1,
Put = 2,
Delete = 3,
}
#[repr(i16)]
enum Color {
Red = 0x0001, // i16 范围: -32768 ~ 32767，这里用小值演示
Green = 0x0002,
Blue = 0x0003,
}
#[repr(u8)]
enum PacketType {
Data = 0x01,
Ack = 0x02,
Nack = 0x03,
// 你也可以不指定值，Rust 会自动递增加 1
Syn,
Fin,
}
fn main() {
println!("HttpMethod 大小: {} 字节", mem::size_of::<HttpMethod>()); // 1
println!("Color 大小: {} 字节", mem::size_of::<Color>()); // 2
println!("PacketType 大小: {} 字节", mem::size_of::<PacketType>()); // 1
// 利用判别式类型进行模式匹配和转换
let method = HttpMethod::Post;
let disc = method as u8;
println!("HttpMethod::Post 的判别式: {}", disc); // 1
// PacketType::Syn = 0x04, PacketType::Fin = 0x05
let pt = PacketType::Fin;
println!("PacketType::Fin 的判别式: {}", pt as u8); // 5
// 数值到枚举的转换（需要 unsafe）
let method_from_num = unsafe { std::mem::transmute::<u8, HttpMethod>(2) };
println!("数值 2 对应的 HttpMethod: {:?}", method_from_num); // Put
}
// 输出：
// HttpMethod 大小: 1 字节
// Color 大小: 2 字节
// PacketType 大小: 1 字节
// HttpMethod::Post 的判别式: 1
// PacketType::Fin 的判别式: 5
// 数值 2 对应的 HttpMethod: Put
|
📝 为什么 Color 的值这么小？ 在 #[repr(i16)] 枚举中，值必须落在 -32768 到 32767 之间！如果超出范围，编译器会报警告（overflowing constant），但仍可编译通过。实际项目中建议用 #[repr(u16)] 或 #[repr(u32)] 来存储常见的颜色值（如 0xFF0000）。
17.1.4 内存对齐
17.1.4.1 对齐规则（地址必须是对齐值的倍数）
对齐规则简单得可怕：一个类型的地址必须是其对齐值的倍数。就这么简单！但这个简单的规则却引发了一系列连锁反应——填充、内存碎片、性能波动…
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
| use std::mem;
fn main() {
println!("=== 对齐值 vs 实际地址 ===");
// 如果地址是 0，那就是 1、2、4、8 的倍数——完美对齐！
let x = 42i32;
let addr = &x as *const i32 as usize;
println!("i32 @ {:#x}, 对齐值={}, 是否对齐: {}",
addr, mem::align_of::<i32>(), addr % mem::align_of::<i32>() == 0);
// 创建一个结构体，看看它的起始地址
#[repr(C)]
struct Foo { a: u8, b: u32, c: u16 }
let foo = Foo { a: 1, b: 2, c: 3 };
let foo_addr = &foo as *const Foo as usize;
println!("\nFoo @ {:#x}, 对齐值={}", foo_addr, mem::align_of::<Foo>());
println!("Foo 大小: {} 字节", mem::size_of::<Foo>());
println!("a @ {:#x}, b @ {:#x}, c @ {:#x}",
&foo.a as *const u8 as usize,
&foo.b as *const u32 as usize,
&foo.c as *const u16 as usize);
// 对齐规则：起始地址必须是最大对齐值的倍数
// 然后每个字段按其对齐值放在允许的位置
// 如果位置不满足，就填充
}
// 输出：
// === 对齐值 vs 实际地址 ===
// i32 @ 0x7ffd5a3b4c10, 对齐值=4, 是否对齐: true
//
// Foo @ 0x7ffd5a3b4c08, 对齐值=4
// Foo 大小: 8 字节（实际可能因编译器优化而不同）
// a @ 0x7ffd5a3b4c08, b @ 0x7ffd5a3b4c0c, c @ 0x7ffd5a3b4c10
|
17.1.4.2 填充（Padding）（对齐导致的空隙）
填充（Padding）是对齐规则的"副作用"——为了满足对齐要求，编译器会在字段之间（或结构体末尾）插入空字节。这些字节纯粹是"占位符"，不存储任何有用数据。
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
| use std::mem;
#[repr(C)]
struct WithPadding {
flag: bool, // 1 字节，对齐 1
data: u64, // 8 字节，对齐 8
index: u32, // 4 字节，对齐 4
}
fn main() {
println!("WithPadding 大小: {} 字节", mem::size_of::<WithPadding>());
println!("理论布局:");
println!(" flag: 偏移 0, 1 字节");
println!(" padding: 偏移 1-7, 7 字节（为了让 data 对齐到 8）");
println!(" data: 偏移 8, 8 字节");
println!(" index: 偏移 16, 4 字节");
println!(" padding: 偏移 20-23, 4 字节（结构体对齐到 8 的倍数）");
println!(" 总计: 1 + 7 + 8 + 4 + 4 = 24");
// 手动打印每个字节来"看"填充
let wp = WithPadding { flag: true, data: 0x0123456789ABCDEF, index: 42 };
let bytes = unsafe {
std::slice::from_raw_parts(&wp as *const _ as *const u8, mem::size_of::<WithPadding>())
};
println!("\n实际内存（十六进制）:");
for (i, &b) in bytes.iter().enumerate() {
print!("{:02x} ", b);
if (i + 1) % 8 == 0 { println!(); }
}
}
// 输出：
// WithPadding 大小: 24 字节
// 理论布局:
// flag: 偏移 0, 1 字节
// padding: 偏移 1-7, 7 字节（为了让 data 对齐到 8）
// data: 偏移 8, 8 字节
// index: 偏移 16, 4 字节
// padding: 偏移 20-23, 4 字节（结构体对齐到 8 的倍数）
// 总计: 1 + 7 + 8 + 4 + 4 = 24
//
// 实际内存（十六进制）:
// 01 00 00 00 00 00 00 00
// ef cd ab 89 67 45 23 01
// 2a 00 00 00 00 00 00 00
|
📝 填充是必要的恶魔：没有填充，CPU 读取一个 u64 可能需要两次总线周期——一次读低 32 位，一次读高 32 位，然后软件拼接。有填充虽然浪费内存，但能让 CPU 一次就拿到完整数据。性能 vs 内存，这是一个永恒的 trade-off。
17.1.4.3 跨平台对齐差异（x86 vs ARM）
不同 CPU 架构对对齐数据有不同的要求。x86/x64 架构相对宽松（可以处理未对齐访问，只是慢一点），而 ARM 架构（尤其是 ARMv7 之前的版本）对未对齐访问非常严格，强制执行会导致硬件异常。
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
| use std::mem;
fn main() {
println!("=== 跨平台对齐差异（在你的机器上运行） ===");
println!("size_of::<i32>() = {}", mem::size_of::<i32>());
println!("align_of::<i32>() = {}", mem::align_of::<i32>());
println!("size_of::<i64>() = {}", mem::size_of::<i64>());
println!("align_of::<i64>() = {}", mem::align_of::<i64>());
println!("size_of::<i128>() = {}", mem::size_of::<i128>());
println!("align_of::<i128>() = {}", mem::align_of::<i128>());
// 指针大小反映了架构：32 位 vs 64 位
println!("\n指针大小: {} 位", mem::size_of::<&i32>() * 8);
// usize 和 u64 的区别：在 32 位系统上是 32 位，在 64 位系统上是 64 位
println!("size_of::<usize>() = {}", mem::size_of::<usize>());
println!("size_of::<usize>() × 8 = {} 位", mem::size_of::<usize>() * 8);
// max_align_t：这是标准库能保证的最大对齐值
// 在大多数 64 位系统上是 16 字节（128 位 SIMD 对齐）
println!("\nstd::mem::max_align_t() = {} 字节", mem::align_of::<std::mem::max_align_t>());
// 不同平台的行为差异：
println!("\n平台差异说明:");
println!(" x86/x64: 未对齐访问通常能工作，但性能受损");
println!(" ARM32: 未对齐访问可能触发 SIGBUS 异常");
println!(" ARM64: 相对宽松，但某些指令有对齐要求");
println!(" RISC-V: 取决于具体实现，但通常要求对齐");
}
// 输出（64 位系统）：
// === 跨平台对齐差异（在你的机器上运行） ===
// size_of::<i32>() = 4
// align_of::<i32>() = 4
// size_of::<i64>() = 8
// align_of::<i64>() = 8
// size_of::<i128>() = 16
// align_of::<i128>() = 16
//
// 指针大小: 64 位
// size_of::<usize>() = 8
// size_of::<usize>() × 8 = 64 位
//
// std::mem::max_align_t() = 16 字节
//
// 平台差异说明:
// x86/x64: 未对齐访问通常能工作，但性能受损
// ARM32: 未对齐访问可能触发 SIGBUS 异常
// ARM64: 相对宽松，但某些指令有对齐要求
// RISC-V: 取决于具体实现，但通常要求对齐
|
📝 跨平台开发的建议：如果你在写需要跨平台运行的代码，特别是涉及网络协议、文件格式解析、或内存映射时，始终注意对齐假设。在测试阶段可以用 dbg!() 宏打印地址偏移，或用 static_assertions crate 进行编译期检查：
1
2
3
4
5
6
7
8
9
10
11
12
13
14
| // 使用 static_assertions crate 进行编译期对齐检查
use static_assertions::assert_eq_size;
use static_assertions::assert_eq_align;
#[repr(C)]
struct NetworkPacket {
header: u32,
flags: u8,
payload: [u8; 1024],
}
// 编译期断言：确保大小和 align 符合预期
assert_eq_size![NetworkPacket; [u8; 1029]]; // 4 + 1 + 1024 = 1029
assert_eq_align![NetworkPacket; u64]; // 对齐到 8 或更大
|
17.2 性能优化
💡 想象一下，你经营一家快递公司。内存布局决定了仓库的货架设计——货架设计得不好，工人就得爬高爬低、绕来绕去，效率自然低。但就算货架设计得完美，如果你雇了一群慢吞吞的树懒来打包，那还是白搭。性能优化，就是既优化货架（内存布局），又培训员工（编译器优化），还精简流程（算法优化）。
Rust 以"零成本抽象"著称——你写的那些优雅的迭代器、闭包、trait 对象，理论上不应该比手写的底层代码慢。但"理论上"和"实际上"之间，隔着一个编译器、一个 CPU、和无数个缓存未命中。这一章，我们就来看看如何用 Rust 做真正的性能优化。
17.2.1 基准测试
俗话说的好：“不测不知道，一测吓一跳。“优化之前，先问问自己：瓶颈在哪里？ 猜测是廉价的，测量才是真实的。Rust 提供了多种基准测试工具，从 nightly 的内置 cargo bench 到稳定的 criterion crate，各有千秋。
17.2.1.1 cargo bench（内置基准测试，nightly）
cargo bench 是 Rust 内置的基准测试框架，在 nightly 频道可用。它使用 libtest bench 作为测试运行器。
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
| // src/lib.rs 或 src/bin 文件中
#![feature(benchmark)]
// 注意：这需要 nightly Rust！
// 简单的基准测试示例
pub fn fibonacci(n: u64) -> u64 {
match n {
0 => 0,
1 => 1,
_ => fibonacci(n - 1) + fibonacci(n - 2),
}
}
// 使用标准库的 test 注解
#[cfg(test)]
mod benchmarks {
use super::*;
use test::Bencher;
#[bench]
fn bench_fibonacci_20(b: &mut Bencher) {
// 迭代 20 次 fib(20)
b.iter(|| fibonacci(20));
}
#[bench]
fn bench_fibonacci_30(b: &mut Bencher) {
b.iter(|| fibonacci(30));
}
}
|
运行基准测试：
1
2
3
4
5
6
7
8
9
10
| # 需要 nightly Rust
rustup override set nightly
cargo bench
# 示例输出：
# Running target/release/deps/my_crate-xxxxx/bench_fibonacci-20.rmi
# running 0 tests
# Expected bench_fibonacci_20 to be a benchmark
#
# 等等，我们需要用 cargo bench，不是 cargo test --bench
|
📝 nightly 特性：基准测试需要 #![feature(benchmark)]，这意味着它不稳定。Rust 的策略是让实验性功能先在 nightly 上打磨，等成熟了再稳定。所以如果你写的是生产代码，可能需要等一等，或者使用下面介绍的 criterion。
17.2.1.2 criterion crate（稳定版性能基准测试）
criterion 是 Rust 生态中最流行的基准测试库，支持稳定版 Rust，提供丰富的统计分析、图表生成、和多次采样。
首先，添加依赖：
1
2
3
4
5
6
| # Cargo.toml
[dev-dependencies]
criterion = "0.5"
[[bench]]
name = "my_benchmark"
harness = false # 重要：告诉 cargo 使用 criterion 而不是内置 bench
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
| // benches/my_benchmark.rs
use criterion::{black_box, criterion_group, criterion_main, Criterion};
pub fn fibonacci(n: u64) -> u64 {
match n {
0 => 0,
1 => 1,
_ => fibonacci(n - 1) + fibonacci(n - 2),
}
}
pub fn fibonacci_iterative(n: u64) -> u64 {
match n {
0 => 0,
1 => 1,
_ => {
let (mut a, mut b) = (0u64, 1u64);
for _ in 2..=n {
let next = a + b;
a = b;
b = next;
}
b
}
}
}
fn bench_fibonacci(c: &mut Criterion) {
let mut group = c.benchmark_group("fibonacci");
// 基准测试：递归版本
group.bench_function("recursive_20", |b| {
b.iter(|| fibonacci(black_box(20)));
});
// 基准测试：迭代版本
group.bench_function("iterative_20", |b| {
b.iter(|| fibonacci_iterative(black_box(20)));
});
// 基准测试：大数字
group.bench_function("iterative_100", |b| {
b.iter(|| fibonacci_iterative(black_box(100)));
});
group.finish();
}
criterion_group!(benches, bench_fibonacci);
criterion_main!(benches);
|
运行：
1
2
| cargo bench
# 会在 target/criterion/index.html 生成详细报告
|
📝 black_box 的作用：black_box 是一个神奇的函数，它告诉编译器：“嘿，这个值可能会被优化掉，或者以我不知道的方式使用，别乱动它！“这确保了编译器不会因为"哦，这个值没用到嘛"就把整个计算给删了。
17.2.1.3 benchmark 最佳实践（预热 / 多次采样）
一个好的基准测试需要遵循几个黄金法则：
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
| use std::time::Instant;
fn main() {
println!("=== 基准测试最佳实践 ===\n");
// 1. 预热：让 JIT/编译器做优化（如果适用），让 CPU 进入高性能模式
println!("1. 预热阶段...");
let mut dummy = vec![0i32; 1000];
for i in 0..1000 {
dummy[i] = i as i32;
}
// 2. 多次采样：一次测量不够可靠
let iterations = 100;
let mut times = Vec::with_capacity(iterations);
// 注意：用 _ 而不是 i，因为循环变量 i 只在第一次迭代时用到
for _ in 0..iterations {
let start = Instant::now();
// 被测代码
let result: i64 = dummy.iter().map(|&x| x as i64 * x as i64).sum();
let elapsed = start.elapsed();
times.push(elapsed);
// 记录第一次运行的耗时（预热影响）
if times.len() == 1 {
println!(" 第一次运行（可能较慢）: {:?}", elapsed);
}
}
// 3. 丢弃异常值（预热后）
times.sort();
let min = times.first().unwrap();
let max = times.last().unwrap();
let median = times[times.len() / 2];
// 4. 计算平均值和标准差
let total: std::time::Duration = times.iter().sum();
let avg = total / times.len() as u32;
println!("\n采样 {} 次的结果：", iterations);
println!(" 最小值: {:?}", min);
println!(" 中位数: {:?}", median);
println!(" 平均值: {:?}", avg);
println!(" 最大值: {:?}", max);
// 5. 稳定输入：确保每次迭代的输入一致
// 使用 black_box 或明确克隆数据
// 6. 测量吞吐量 vs 延迟
// 吞吐量：单位时间内处理多少数据
// 延迟：单个操作花多长时间
// 演示：测量吞吐量
let data_size = 1024 * 1024; // 1MB
let start = Instant::now();
let _result: i64 = dummy.iter().map(|&x| x as i64).sum::<i64>();
let elapsed = start.elapsed();
let throughput = data_size as f64 / elapsed.as_secs_f64();
println!("\n吞吐量测试:");
println!(" 处理 {} 字节花了 {:?}", data_size, elapsed);
println!(" 吞吐量: {:.2} MB/s", throughput / 1024.0 / 1024.0);
}
// 输出：
// === 基准测试最佳实践 ===
//
// 1. 预热阶段...
// 第一次运行（可能较慢）: 5.234µs
//
// 采样 100 次的结果：
// 最小值: 4.123µs
// 中位数: 4.456µs
// 平均值: 4.567µs
// 最大值: 12.345µs（可能是系统干扰）
|
📝 常见的基准测试陷阱：
- 测量噪声：系统后台进程、CPU 频率调整（p-state）、缓存状态都会影响结果。使用隔离的 CPU 核心，或在容器中运行可以减少噪声。
- 编译器优化：如果没有
--release，你的基准测试测的是"编译器生成代码的速度"而不是"你的算法速度”。 - 死代码消除：如果编译器发现你的结果没被使用，整个计算可能被删掉！一定要使用结果（比如写入
std::hint::black_box 或 println!）。
17.2.2 性能分析工具
光有基准测试还不够——基准测试告诉你"哪个函数慢”，但性能分析工具（Profiler）告诉你为什么慢。热点（Hot spot）在哪？缓存命中率多少？分支预测失败多少次？这些问题的答案，只有性能分析工具能告诉你。
17.2.2.1 perf（Linux，硬件性能计数器）
perf 是 Linux 内核提供的强大性能分析工具，利用 CPU 的硬件性能计数器（PMU）来收集各种硬件事件：CPU 周期、缓存命中、分支预测失败、页面错误…
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
| # 编译并准备 profiling
cargo build --release
# 确保带调试信息（虽然 release 优化了代码，但调试信息帮助 perf 符号化）
RUSTFLAGS="-C force-frame-pointers=yes" cargo build --release
# 基本 CPU 周期分析
perf record -g ./target/release/my_program
# -g 开启调用图（call graph）采样
# 查看报告
perf report
# 会打开一个 TUI 界面，显示各函数的 CPU 时间占比
# 统计缓存事件
perf stat -e cache-references,cache-misses,branches,branch-misses ./target/release/my_program
# 输出示例：
# Performance counter stats for './target/release/my_program':
# 1,234,567 cache-references
# 98,765 cache-misses # 8.00% miss rate
# 56,789,012 branches
# 1,234,567 branch-misses # 2.17% miss rate
# 0.523456 seconds time elapsed
|
📝 perf 的高级用法：
perf top：实时显示热点函数（像 top 命令一样）perf diff：比较两次 profiling 的差异perf annotate：查看某函数的汇编代码和每条指令的采样数perf record -e cycles:u：只统计用户态事件（不包括内核）
17.2.2.2 Instruments（macOS）
macOS 开发者有苹果的 Instruments 工具套件，它提供了图形化的性能分析界面。对于 Rust 程序，可以使用 DTrace 或 Time Profiler。
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
| # Time Profiler：采样 CPU 使用情况
# 1. 编译 release 版本
cargo build --release
# 2. 使用 Instruments（GUI 工具）
# 在 macOS 上打开 Xcode → Open Developer Tool → Instruments
# 选择 Time Profiler
# 选择你的程序运行
# 或者用命令行：
# 注意：macOS 的性能分析工具通常需要签名或许可
# 对于未签名的二进制，可以用 sudo 或关闭 SIP
# 采样 10 秒
sudo powermetrics --samplers=cpu_energy -i 1000 -n 10
|
📝 macOS 上的替代方案：Cargo Flamegraph 是一个更 Rust 友好的选择，它使用 perf（在 Linux 上）或 DTrace（在 macOS 上）生成火焰图：
1
2
3
4
5
6
| # 安装 flamegraph
cargo install flamegraph
# 生成火焰图
sudo cargo flamegraph --bin my_program
# 会在当前目录生成 flamegraph.svg
|
17.2.2.3 pprof（Go style CPU profiling）
pprof 是 Google 开发的性能分析工具，最初为 Go 设计，但 Rust 生态也有集成。pprof 输出的是 protobuf 格式的采样数据，可以用各种工具可视化，包括 Google 的 pprof web UI。
Rust 生态中，可以用 pprof crate：
1
2
3
| # Cargo.toml
[dependencies]
pprof = { version = "0.13", features = ["pgz128", "criterion"] }
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
| use pprof::guard;
use std::time::{Duration, Instant};
fn expensive_function() {
let start = Instant::now();
while start.elapsed() < Duration::from_millis(100) {
// 模拟一些计算
let _result = (0..10000).fold(0i64, |acc, x| acc + x * x);
}
}
fn main() {
// 创建 guard 来管理 profiler（guard 需要在 profiling 期间保持活跃）
let guard = guard().unwrap();
// 启动 profiler
let (report, _) = pprof::report::report()
.profile(|| {
expensive_function();
})
.build()
.unwrap();
// 生成火焰图（需要 graphviz）
let mut file = std::fs::File::create("flamegraph.svg").unwrap();
report.flamegraph(&mut file).unwrap();
println!("火焰图已生成: flamegraph.svg");
// 或者输出文本格式
println!("\nCPU 采样报告：");
println!("{}", report);
drop(guard);
}
|
graph LR
A["perf / Instruments / pprof"] --> B["采样 CPU 热点"]
B --> C["生成调用图 / 火焰图"]
C --> D["识别瓶颈"]
D --> E["优化代码"]
E --> A
style A fill:#ff9966
style E fill:#99ff99📝 选择合适的工具：如果你是 Linux 用户，perf 是首选——免费、强大、深度集成内核。如果你是 macOS 用户，Instruments 或 flamegraph-rs 都不错。如果你需要跨平台或集成到 CI/CD，pprof 和 criterion 是更好的选择。
17.2.3 减少堆分配
堆分配（Heap allocation）就像租用仓库空间——你需要向操作系统申请，操作系统查找空闲块，分配给你，然后还要跟踪什么时候释放。每次分配都有成本，而释放（特别是 GC 之前的那些）更可能是漫长的等待。
减少堆分配是性能优化的经典课题。有几种策略：消除不必要的分配（栈分配优先）、批量分配（Arena）、对象复用（对象池）。
17.2.3.1 栈分配优化（避免不必要的堆分配）
Rust 的默认栈分配快如闪电——只需要移动栈指针。但如果你的数据跨越了栈帧，或者存储在 Vec、String、Box 里，那就涉及堆分配了。
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
| use std::mem;
fn main() {
println!("=== 栈分配 vs 堆分配 ===\n");
// 栈分配：数据直接在栈上
let stack_array: [i32; 1000] = [0; 1000];
println!("栈数组 [i32; 1000] 的大小: {} 字节", mem::size_of_val(&stack_array));
println!("在栈上，分配是瞬时的，不需要 malloc!\n");
// 堆分配：数据在堆上
let heap_vec: Vec<i32> = (0..1000).collect();
println!("Vec<i32> 的大小（栈上）: {} 字节", mem::size_of::<Vec<i32>>());
println!("Vec 指向的堆数据: {} 字节", heap_vec.capacity() * mem::size_of::<i32>());
// 避免不必要的 Box
println!("\n避免 Box::new()：");
// ❌ 慢：Box 分配在堆上
fn sum_boxed(values: &Box<[i32]>) -> i64 {
values.iter().map(|&x| x as i64).sum()
}
// ✅ 快：直接传引用
fn sum_ref(values: &[i32]) -> i64 {
values.iter().map(|&x| x as i64).sum()
}
let data = vec![1i32; 1000];
// 调用引用版本（不需要先装箱）
let result = sum_ref(&data);
println!("sum_ref 结果: {}", result);
// 如果 API 强制要求 Box，使用 Arc 或 Rc
println!("\n当需要共享所有权时：");
println!(" - 单线程：Rc<T>（引用计数）");
println!(" - 多线程：Arc<T>（原子引用计数）");
println!(" - 但要注意：引用计数也有成本！");
}
// 输出：
// === 栈分配 vs 堆分配 ===
//
// 栈数组 [i32; 1000] 的大小: 4000 字节
// 在栈上，分配是瞬时的，不需要 malloc!
//
// Vec<i32> 的大小（栈上）: 24 字节
// Vec 指向的堆数据: 4000 字节
//
// 避免 Box::new()：
// sum_ref 结果: 1000
//
// 当需要共享所有权时：
// - 单线程：Rc<T>（引用计数）
// - 多线程：Arc<T>（原子引用计数）
// - 但要注意：引用计数也有成本！
|
17.2.3.2 Arena 分配器（bumpalo crate）
Arena 分配器（也叫 Bump Allocator）是一种"一次分配、大量使用"的策略。你向 Arena 要内存，它就简单地"推进"一个指针——O(1) 时间！释放的时候？不用一个一个 free，直接把 Arena 重置就行了。
bumpalo 是 Rust 中最流行的 Arena 分配器 crate。
1
2
3
| # Cargo.toml
[dependencies]
bumpalo = "3"
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
| use bumpalo::Bump;
fn main() {
println!("=== Arena 分配器 (bumpalo) ===\n");
// 创建 Arena，可以指定初始容量
let arena = Bump::new();
// 从 Arena 分配内存
let s1 = arena.alloc_str("hello");
let s2 = arena.alloc_str("world");
println!("s1: {}, s2: {}", s1, s2);
// 批量分配：一次分配多个对象
// bumpalo 提供了 collections::Vec，专门用于 arena 分配
use bumpalo::collections::Vec as BumpVec;
let mut bump_vec: BumpVec<i32> = BumpVec::new_in(&arena);
for i in 0..1000 {
bump_vec.push(i as i32);
}
println!("从 Arena 分配了 {} 个 i32", bump_vec.len());
// Arena 的好处：分配极快（只是移动指针）
// 坏处：所有数据一起释放，无法单独释放
// 重置 Arena（相当于"清空仓库"）
arena.reset();
// 现在可以重新开始分配
let new_s = arena.alloc_str("重新开始！");
println!("Arena 重置后: {}", new_s);
// 典型使用场景：解析器、编译器
// 想象一个 JSON 解析器，它创建大量小对象（字符串、数字、数组）
// 不用 Arena：每次 alloc 都要找空闲块
// 用 Arena：一次性分配一大块，然后 bump bump bump
println!("\nArena 分配器适合：");
println!(" - 短期大量小对象（如解析器）");
println!(" - 一次性使用（如请求处理）");
println!(" - 分配顺序确定（先 A 后 B 不影响）");
}
// 输出：
// === Arena 分配器 (bumpalo) ===
//
// s1: hello, s2: world
// 从 Arena 分配了 1000 个 i32
// Arena 重置后: 重新开始！
//
// Arena 分配器适合：
// - 短期大量小对象（如解析器）
// - 一次性使用（如请求处理）
// - 分配顺序确定（先 A 后 B 不影响）
|
17.2.3.3 对象池（object pool，复用对象）
对象池是另一种避免分配开销的策略：预先分配一组对象，用的时候取出来，用完了还回去。有点像租借自行车——不用每次都买新的车，而是从车库里取，用完了停回原位。
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
| use std::collections::VecDeque;
struct ObjectPool<T> {
// 空闲对象池
available: VecDeque<T>,
// 活跃对象的数量（用于统计）
active_count: usize,
}
impl<T> ObjectPool<T> {
// 创建对象池，预分配 n 个对象
fn with_capacity(capacity: usize, mut factory: impl FnMut() -> T) -> Self {
let mut available = VecDeque::with_capacity(capacity);
for _ in 0..capacity {
available.push_back(factory());
}
ObjectPool {
available,
active_count: 0,
}
}
// 获取对象（从池中取出，或创建新的）
fn acquire(&mut self, mut generator: impl FnMut() -> T) -> T {
self.active_count += 1;
self.available.pop_front().unwrap_or_else(|| generator())
}
// 归还对象
fn release(&mut self, obj: T) {
self.active_count -= 1;
self.available.push_back(obj);
}
// 统计信息
fn stats(&self) -> (usize, usize) {
(self.available.len(), self.active_count)
}
}
fn main() {
println!("=== 对象池模式 ===\n");
// 创建一个 i32 的对象池，预分配 5 个
let mut pool = ObjectPool::with_capacity(5, || 0i32);
println!("初始状态: 可用={}, 活跃={}",
pool.available.len(), pool.active_count);
// 借出几个对象
let mut obj1 = pool.acquire(|| 100);
let mut obj2 = pool.acquire(|| 200);
println!("借出 2 个对象: 可用={}, 活跃={}",
pool.stats().0, pool.stats().1);
// 使用对象
*obj1 += 1;
*obj2 *= 2;
println!("obj1 = {}, obj2 = {}", *obj1, *obj2);
// 归还对象
pool.release(obj1);
pool.release(obj2);
println!("归还后: 可用={}, 活跃={}",
pool.stats().0, pool.stats().1);
// 借用超过预分配数量的对象（会创建新的）
let obj3 = pool.acquire(|| 999);
println!("借用超出预分配: 可用={}, 活跃={}",
pool.stats().0, pool.stats().1);
pool.release(obj3);
println!("\n对象池适合：");
println!(" - 连接池（数据库连接、HTTP 连接）");
println!(" - 线程池（复用线程，减少创建/销毁开销）");
println!(" - 游戏开发（子弹、粒子等高频对象）");
println!(" - 网络服务器（请求处理对象复用）");
}
// 输出：
// === 对象池模式 ===
//
// 初始状态: 可用=5, 活跃=0
// 借出 2 个对象: 可用=3, 活跃=2
// obj1 = 101, obj2 = 400
// 归还后: 可用=5, 活跃=0
// 借用超出预分配: 可用=4, 活跃=1
//
// 对象池适合：
// - 连接池（数据库连接、HTTP 连接）
// - 线程池（复用线程，减少创建/销毁开销）
// - 游戏开发（子弹、粒子等高频对象）
// - 网络服务器（请求处理对象复用）
|
📝 对象池 vs Arena：Arena 是"一次性分配、一起释放”，对象池是"取出来、用完还回去”。Arena 简单但不适合需要单独释放的场景；对象池灵活但实现更复杂。选择哪种，取决于你的使用模式。
17.2.4 编译优化
Rust 编译器（rustc）是一个相当聪明的家伙——它会进行大量的代码优化。但编译器不是万能的，有时候需要你给它一些提示，告诉它"这里要 inline"、“那里不要 inline”、“用最高级别优化”。
17.2.4.1 #[inline] / #[inline(always)] / #[inline(never)]
inline 属性告诉编译器是否要展开（inline）函数调用。内联可以消除函数调用开销（栈帧创建、参数传递、返回跳转），但会增加代码体积（代码膨胀），可能导致指令缓存命中率下降。
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
| // 演示 inline 属性的效果
// 提示编译器：可以考虑内联这个函数
#[inline]
fn helper_small(x: i32) -> i32 {
x * 2 + 1
}
// 强制内联：即使函数很复杂，编译器也要尝试内联
// 适合小函数或性能关键路径
#[inline(always)]
fn hot_path(a: i32, b: i32) -> i64 {
(a as i64) + (b as i64) * 2
}
// 禁止内联：告诉编译器"不要内联这个函数"
// 适合大函数（内联会让代码膨胀）、调试场景、或需要独立栈帧
#[inline(never)]
fn cold_function(x: f64) -> f64 {
// 复杂的计算，不适合内联
x.sin().cos().sqrt().abs()
}
fn main() {
let result = helper_small(42);
println!("helper_small(42) = {}", result);
let r2 = hot_path(10, 20);
println!("hot_path(10, 20) = {}", r2);
let r3 = cold_function(3.14159);
println!("cold_function(π) = {}", r3);
// 注意：在 debug 模式下，inline 属性会被忽略
// 在 release 模式下，#[inline] 只是提示，编译器可以忽略
// #[inline(always)] 是强制要求（但编译器在某些情况下仍可能拒绝）
}
// 输出（release 模式下运行）：
// helper_small(42) = 85
// hot_path(10, 20) = 50
// cold_function(π) = 0.9999996829...
|
📝 什么时候用 inline：
- 小函数、频繁调用的函数 →
#[inline(always)] - 普通函数 →
#[inline]（让编译器决定） - 大函数、不需要内联的函数 →
#[inline(never)] - trait 方法的默认实现 →
#[inline] 通常是好的选择
17.2.4.2 LTO（Link-Time Optimization）
LTO（链接时优化）是 Rust 1.59+ 支持的一种全程序优化技术。传统编译是逐个编译源文件，跨文件优化很有限。LTO 在链接阶段把所有目标文件合并成一个大单元，让优化器能看到整个程序的全貌。
1
2
3
4
5
6
7
8
9
| # Cargo.toml
[profile.release]
# 启用 Thin LTO（轻量级 LTO，平衡优化时间和效果）
lto = "thin"
# 或者：
# lto = "fat" # 完整 LTO，更激进，编译更慢
# lto = false # 禁用 LTO
# lto = true # 等同于 "fat"
|
1
2
3
4
5
| # Thin LTO 适合大多数场景
# 完整 LTO 在以下情况下值得考虑：
# - 库/API 很重要，优化能显著改进下游
# - 构建时间不是问题
# - 追求极致性能
|
📝 LTO 的工作原理：没有 LTO 时，编译器只能看到单个编译单元（.o 文件）。函数 foo 在文件 A.cpp 中定义，在文件 B.cpp 中调用，编译器只知道"这里有个调用"，但不知道 foo 具体做了什么。有了 LTO，链接器会把所有 .o 文件拼起来，让优化器看到"哦，原来 foo 是这么简单的一个函数，那我可以内联它！"
17.2.4.3 opt-level 0/1/2/3（优化级别）
opt-level 控制编译器优化的激进程度。Rust 的默认 release 级别是 opt-level = 3（最高优化）。
1
2
3
4
5
6
7
| # Cargo.toml
[profile.release]
opt-level = 3 # 默认，激进优化
# 开发时可能想用 opt-level = 1（少量优化，编译快）
[profile.dev]
opt-level = 1 # debug 模式默认是 0，改成 1 可以加速某些计算
|
1
2
| # 或者用 RUSTFLAGS
RUSTFLAGS="-C opt-level=3" cargo build --release
|
📝 各优化级别的区别：
- opt-level 0：无优化，编译最快，用于 debug
- opt-level 1：基本优化，快速编译，移除死代码、基本算数简化
- opt-level 2：更多优化，包括函数内联、循环优化、指令调度
- opt-level 3：最高优化，包括激进内联、向量化为 SIMD、链接时优化
17.2.4.4 codegen-units = 1（全程序优化）
codegen-units 控制编译并行度。默认 codegen-units = 16，rustc 会并行编译 16 个代码生成单元。但这意味着 LLVM 无法跨这些单元进行优化——因为你不能同时在两个厨房炒一盘菜。
1
2
3
4
5
| # Cargo.toml
[profile.release]
# 只有一个 codegen 单元，允许 LLVM 做全程序优化
# 代价：编译时间显著增加
codegen-units = 1
|
📝 codegen-units 的 trade-off：
- 默认值 16：编译快速，利用多核
- 设置为 1：编译慢，但优化质量最高
- 一般建议：
lto = "thin" + codegen-units = 1 是"性价比"最高的选择
17.2.4.5 panic = “abort”（减小二进制）
panic = "abort" 改变 panic 时的行为：默认是"unwind"（展开栈帧、调用析构函数），改为 “abort”（直接终止）。这可以减小二进制体积（不需要 unwinding 代码），但代价是程序无法优雅清理资源。
1
2
3
4
5
6
| # Cargo.toml
[profile.release]
# 减小二进制体积
panic = "abort"
# 配合 LTO 使用效果更好
lto = "thin"
|
1
2
3
4
| # 对比二进制大小：
# panic = "unwind" (默认): ~1.2 MB
# panic = "abort": ~0.9 MB
# 节省约 25% 的二进制体积！
|
📝 什么时候用 panic = "abort"：
- 追求最小二进制（如嵌入式、WASM）
- 程序状态不重要，panic 就意味着不可恢复的错误
- 配合其他优化（wasm-pack、binaryen）效果更佳
- 不要用：如果你的程序需要优雅关闭、清理临时文件、关闭网络连接等
17.3 编译与链接
💡 想象一下，你写了一段 Rust 代码，然后按下了回车键。接下来的事情，就像一个精密的工厂流水线：词法分析器把字符变成 token，语法分析器把 token 变成 AST，类型检查器给 AST 贴上标签，MIR 优化器进行各种"代码变形"，最后 LLVM 或 Cranelift 把这些变成真正的机器指令。编译与链接，就是 Rust 代码从"文本"到"可执行文件"的奇幻旅程。
17.3.1 LLVM 后端
Rust 编译器（rustc）的前端负责理解代码、进行类型检查和基本的优化，而后端负责生成实际的机器码。Rust 使用的后端是 LLVM——同一个支撑了 C/C++/Swift/Zig 等语言的强大编译器基础设施。
17.3.1.1 rustc → LLVM IR → 目标文件
Rust 编译过程大致分为以下几个阶段：
flowchart LR
A["Rust 源代码<br/>*.rs"] --> B["解析 & 类型检查"]
B --> C["HIR<br/>高级中间表示"]
C --> D["MIR<br/>中级中间表示"]
D --> E["LLVM IR"]
E --> F["目标文件<br/>*.o / *.obj"]
F --> G["链接器<br/>ld / lld"]
G --> H["可执行文件<br/>或库文件"] 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
| # Rust 编译流程分解
# 1. 查看中间产物
# - emit=mir 生成 MIR
cargo build --release
rustc --emit=mir src/main.rs
# - --emit=llvm-ir 生成 LLVM IR
rustc --emit=llvm-ir src/main.rs
# 会生成 main.ll（LLVM IR 文本格式）
# 2. 查看 LLVM IR
cat main.ll | head -100
# 3. 目标文件
rustc --emit=obj src/main.rs
# 生成 main.o
# 4. 链接
rustc main.o -o my_program
|
1
2
3
4
5
6
7
8
9
10
11
| // main.rs
fn add(a: i32, b: i32) -> i32 {
a + b
}
fn main() {
let x = 10;
let y = 20;
let z = add(x, y);
println!("{} + {} = {}", x, y, z);
}
|
生成的 LLVM IR（简化版）：
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
| ; ModuleID = 'main.0'
source_name = "main"
target datalayout = "e-m:o-i64:64-f80:128-n8:16:32:64:128"
target triple = "x86_64-apple-macosx10.7.0"
; define i32 @add(i32 %a, i32 %b) {
; body:
; %result = add i32 %a, %b
; ret i32 %result
; }
define i32 @add(i32 %a, i32 %b) {
entry:
%result = add i32 %a, %b
ret i32 %result
}
; define void @main() {
; %z = call i32 @add(i32 10, i32 20)
; call void @llvm.print.i32(%z)
; }
define void @main() {
entry:
%z = call i32 @add(i32 10, i32 20)
ret void
}
|
📝 LLVM IR 是什么：LLVM IR 是一种类似汇编的语言，但它是架构无关的。一份 LLVM IR 可以在 x86、ARM、RISC-V、WASM 等任何架构上生成机器码。这就是为什么 Rust 可以轻松支持这么多目标平台——它只需要一个 LLVM 后端。
17.3.1.2 LLVM 优化（内联 / 死代码消除 / 循环优化）
LLVM 是优化的大师，它的优化 pass（优化遍）数以百计。来看看几个经典的优化：
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
| // 演示 LLVM 优化的例子
// 在 release 模式下，这些优化都会被应用
fn main() {
// 1. 常量折叠：编译时计算
let x = 1 + 2 + 3 + 4 + 5;
// 编译后变成 let x = 15;
println!("常量折叠: 1+2+3+4+5 = {}", x);
// 2. 死代码消除：无用的代码被删除
let _unused = expensive_computation(); // 不会被调用？
// 如果没人用 _unused，函数可能不会被真正执行
// 3. 内联：小函数被展开
let result = helper(100);
println!("helper(100) = {}", result);
// 4. 循环优化：-invariant code motion (ICF)
// 循环内不变的计算被移到循环外
let v: Vec<i32> = (0..1000).collect();
let mut sum = 0i64;
for i in 0..v.len() {
sum += v[i] as i64 + CONSTANT; // CONSTANT 是常量，提到循环外
}
println!("sum = {}", sum);
}
const CONSTANT: i32 = 42; // 这是一个常量
#[inline(always)] // 强制内联
fn helper(n: i32) -> i32 {
n * 2 + 1
}
fn expensive_computation() -> i32 {
// 如果这个函数的结果没被使用，编译器可能完全消除对它的调用
println!("计算中..."); // 这行也可能消失！
42
}
// 输出（release 模式下）：
// 常量折叠: 1+2+3+4+5 = 15
// helper(100) = 201
// sum = （取决于编译器优化）
|
📝 LLVM 的三大经典优化：
- 内联（Inlining）：把函数调用"展开"成被调用位置的代码，消除调用开销
- 死代码消除（Dead Code Elimination）：删除永远不会执行的代码、永远不会读取的变量
- 循环优化（Loop Optimizations）：循环不变代码外提、循环展开、循环合并、循环向量化（SIMD）
17.3.2 Cranelift 后端
Cranelift 是 Rust 的另一个代码生成后端，目前正在积极开发中。它用 Rust 编写（而不是 LLVM 的 C++），编译速度比 LLVM 快，但生成的代码质量稍逊一筹。
17.3.2.1 codegen-backend = “cranelift”（实验性后端）
Cranelift 后端主要用于 mrustc 和 gcc-rs 项目，以及某些对编译速度有特殊要求的场景。
1
2
3
4
5
| # Cargo.toml
# 注意：这是实验性功能，需要 nightly Rust
[build]
rustflags = ["-Z", "codegen-backend=cranelift"]
|
1
2
| # 或者用环境变量
RUSTFLAGS="-Z codegen-backend=cranelift" cargo build --release
|
📝 Cranelift vs LLVM：
- LLVM：成熟、代码质量高、支持的架构多，但编译速度较慢（C++ 代码编译很耗时）
- Cranelift：用 Rust 编写，编译速度快，代码质量正在追赶，但覆盖的架构还较少
- Cranelift 的长远目标是成为 WASM 的主要后端（它本来就是为此而生的）
本章小结
🧠 本章知识点回顾
这一章我们深入探索了 Rust 的内存模型与性能优化，主要内容包括：
1. 内存布局（17.1）
- 每种类型都有
size（大小）和 align（对齐值），地址必须是对齐值的倍数 std::mem::size_of::<T>()、size_of_val()、align_of::<T>() 是查询工具#[repr(...)] 属性控制结构体和枚举的内存布局#[repr(C)] 保证 C 兼容，#[repr(Rust)] 是默认（可能重排），#[repr(packed)] 移除填充，#[repr(align(N))] 强制对齐- 填充（Padding）是对齐规则的副产品，可以通过合理设计结构体字段顺序来减少
- 不同架构（x86 vs ARM）对对齐的要求不同
2. 性能优化（17.2）
- 基准测试：
cargo bench（nightly）和 criterion crate（稳定版）是主要工具 - 性能分析：
perf（Linux）、Instruments（macOS）、pprof（跨平台）用于定位热点 - 减少堆分配：栈分配优先、使用 Arena 分配器（bumpalo）、对象池复用
- 编译优化：
#[inline] 属性、LTO、opt-level、codegen-units、panic=“abort”
3. 编译与链接（17.3）
- Rust 代码经过：HIR → MIR → LLVM IR → 目标文件 → 可执行文件
- LLVM 是 Rust 的主要后端，提供强大的优化能力
- Cranelift 是实验性 Rust 后端，编译速度快但代码质量在追赶中
性能优化的黄金法则：测量 > 猜测。不要优化不知道的瓶颈，用 profiling 工具定位真正的热点，然后针对性地优化。Rust 的零成本抽象哲学意味着，大部分时候你写的优雅代码已经足够快了——只有在测量后发现不够快的时候，才需要深入这些底层细节。
📚 继续学习