【iOS】内存地图：从虚拟地址空间到 VM Region

#分段

分段（Segmentation）是一种经典的内存管理思想：按照代码、数据、栈等逻辑单元描述地址空间，各段长度可以不同。它有助于理解” 程序可以由不同用途、不同权限的区域组成”。

但这里必须区分三个名字相似、含义不同的概念：

• 操作系统教材中的 Segmentation 是一种地址转换和内存管理模型。
• Mach-O 中的 __TEXT、__DATA 等 Segment 是可执行文件及其装载映射的组织方式。
• 堆和栈是进程运行时使用的虚拟内存区域，不是 ”编译器创建的 CPU 分段”。

现代 arm64 iOS 的内存管理重点是分页和 Mach VM。后文讨论 Mach-O 时，还需要进一步观察 __TEXT、__DATA 等文件布局如何被映射为进程中的 VM Region。

#分页

为了方便映射和管理，虚拟内存和物理内存都被分割成相同大小的单位，物理内存的最小单位被称为帧（Frame），而虚拟内存的最小单位被称为页（Page）。 Apple 的虚拟内存资料说明，较新的 64 位 iOS 设备通常向用户空间暴露 16 KB 页面，Jetsam Event Report 的官方示例也是 16 KB；具体值仍应以设备和运行环境为准，可以通过 vm_page_size、getpagesize() 或报告中的 pageSize 字段确认，而不应在程序逻辑中写死。

• 页表（Page Table）：记录虚拟页到物理页的映射及读、写、执行等权限。代码访问虚拟地址时，CPU 内部的 MMU（Memory Management Unit） 会依据页表完成地址转换。
• 虚拟内存区域（VM Region）：一段具有相同属性的连续虚拟地址范围。一个进程拥有许多 VM Region，但整个虚拟地址空间并非从头到尾连续有效。

内核建立和管理虚拟内存映射时以页为基本粒度，但这不意味着每次 malloc 几个字节都会单独浪费一个 16 KB 页面。用户态内存分配器会先取得并管理较大的虚拟内存区域，再把其中的小块空间分给不同对象；这就是后文讨论 “堆” 时需要建立的连接。

#按需分页与 Page Fault（缺页中断）

1. 虚拟映射与延迟分配 (Lazy Allocation)

   当系统为进程分配虚拟内存，或通过 mmap 映射文件时，首先建立的是一段合法的 VM Region。建立一段虚拟地址映射，不等于立即占用同等大小的物理 RAM；页面可能按需进入物理内存，映射本身及页表等管理结构仍会产生一定开销，因此不能笼统写成 “实际消耗为零”。

2. 触发调度 (Page Fault 机制)

   当 CPU 首次真正读写某个尚未驻留在物理内存的虚拟页时，现有的页表无法完成地址转换，从而触发缺页中断 (Page Fault)。这是一个正常的、连接虚拟与物理空间的桥梁，并非程序错误。

3. 内核介入与数据准备

   内核接管中断后，会根据该虚拟页的属性进行动态修复：

   • 读取数据 (Page In)： 如果是映射文件，内核会从文件或系统缓存中取得相应内容。
   • 其他策略： 内核也可能分配一个全零填充页 (Zero-Fill)，或者为只读共享页创建一个私有副本 (Copy-on-Write)。

   页面怎样被统计、压缩或回收，以及 iOS 在内存压力下怎样处理进程，属于系列下一篇的范围。

4. 异常边界 内核完成修复后，原指令可以继续执行；如果访问的是未映射地址，或者违反了 Region 的读写执行权限，进程通常会收到 EXC_BAD_ACCESS。因此，Page Fault 本身可以是正常的按需分页过程，只有无法修复的地址或权限错误才会成为程序可见的异常。

这里先把 Page Fault 当作一个连接点：它解释了为什么 ”已经分配或映射虚拟地址” 仍不代表 ”对应物理页已经到位”。系列下一篇讨论 malloc、首次写入和 Memory Footprint 时还会再次用到这个结论。Apple 的 About the Virtual Memory System 对 soft fault、hard fault 和 page-in 有进一步说明。

关于分页、页表和地址转换的更多细节，可以继续阅读：小林 Coding：为什么要有虚拟内存？。本文暂时停在能够支撑后续 iOS 地址空间分析的程度。

#阶段一：App 还没有运行

这时候 App 的代码和数据存放在磁盘上的 Mach-O 文件中。

1
磁盘上的 Mach-O
2
├── __TEXT：代码、部分只读内容
3
├── __DATA_CONST：部分只读数据
4
├── __DATA：可写的全局、静态数据
5
└── 其他装载和链接信息

#阶段二：用户启动 App

系统创建一个进程，并提供一套独立的虚拟地址空间，而不是直接交给它一整块连续物理内存。随后，内核和 dyld 根据 Mach-O 的装载信息建立相关映射；依赖的系统 Framework、动态库和 dyld shared cache 也会进入进程地址空间。

所以进程的完整虚拟地址空间，远大于主程序自己的 Mach-O。

#阶段三：用 VM Region 描述这些映射

虚拟地址空间不是一个从头到尾全部有效的大数组，而是由许多离散的 VM Region 组成。 一个 VM Region 可以先理解为：

一段连续的虚拟地址范围，这段范围具有相近的来源、用途和访问权限。

#阶段四：App 开始运行，堆和线程栈出现

Mach-O 主要解释启动时已经存在的代码和全局数据，但程序运行起来以后，还会不断产生新的内存需求。

• 每创建一个线程，系统都会为这个线程准备自己的栈 Region。
• 当程序执行 malloc 或创建普通 Objective-C 对象时，运行时需要动态分配内存。这些分配通常来自分配器管理的区域；分配器会向系统取得并管理一个或多个 VM Region，再把其中的小块空间交给对象和缓冲区。

本文到这里仍然只讨论 “地址从哪里来”。页面是否驻留、系统怎样统计与回收，以及内存压力下的行为，留到系列下一篇展开。

#阶段五：CPU 真正访问这些地址

无论一个地址属于代码、全局变量、堆还是栈，程序看到的首先都是虚拟地址。CPU 访问时，MMU 和页表参与地址转换；如果映射有效且权限允许，访问最终落到相应的物理页。

#static

上面代码里的 staticNumber 只是文件作用域的 static。static 关键字在 C/Objective-C 里其实控制两件不同的事，容易被 ”是不是进静态区” 这一个问题混在一起：

第一种不会改变对象原本的静态存储期，主要影响符号能否被其他编译单元引用；第二种则让一个作用域仍在函数内的名字，对应到一份贯穿程序执行期的存储。用一段实验代码观察第二种行为：

1
__attribute__((noinline, optnone))
2
void RunStaticCallCountTest(void) {
3
    static int staticCallCount = 0;
4
    int localCallCount = 0;
5
    staticCallCount++;
6
    localCallCount++;
7

8
    NSLog(@"staticCallCount 地址 = %p，值 = %d", &staticCallCount, staticCallCount);
9
    NSLog(@"localCallCount 地址 = %p，值 = %d", &localCallCount, localCallCount);
10
}

连续调用两次 RunStaticCallCountTest()，在 iOS 模拟器（iPhone 16 Pro，iOS 26.5，Xcode 26.6，Debug，-O0）上实测：

用 memory region 查询 0x1043a4960 落在 0x1043a4000–0x1043a8000 rw-，与该次运行中 globalNumber／staticNumber 所在的可写数据 Region 是同一块——说明这个函数局部 static 对象由静态可写数据映射承载，而不是当前线程栈。两次调用中它的地址不变、值从 1 累加到 2，跨调用保留了状态。

localCallCount 的地址在这两次调用之间也没变，这是本次模拟器 Debug 构建复用了同一段栈帧的结果，不代表栈变量本身具有跨调用保留状态的能力；它的值每次都重新是 1，说明栈上的存储在每次调用时都被重新初始化，与 staticCallCount 的行为形成对照。

#Segment 与 Section

Mach-O 使用两层结构组织内容：

• Segment 是装载和权限管理的大单位，例如 __TEXT、__DATA_CONST、__DATA。
• Section 位于 Segment 内部，用于继续区分具体内容，例如 __text、__cstring、__data、__common。

这里还有两个容易忽略的区域：

• __PAGEZERO 在 64 位 Mach-O 中保留低地址范围，不映射为可访问内存，有助于让空指针附近的访问尽早失败。
• __LINKEDIT 保存符号、字符串表、重定位等链接信息，服务于装载、符号解析和调试，但它不属于 ”五大分区” 里的业务数据。

Mach-O 中记录的是链接时虚拟地址、大小和权限等装载信息。启动时，内核和 dyld 根据这些信息建立 VM Region，并继续映射依赖的 Framework 与 dyld shared cache。最终进程地址空间远大于主程序自己的 Mach-O。

#ASLR：为什么每次运行的地址可能不同

为了避免二进制每次都出现在固定地址，系统会在加载时引入随机的 ASLR Slide。

1
运行时地址 = Mach-O 中的链接地址 + ASLR Slide

同一份二进制连续启动两次时，RunSimpleMemoryTest 的绝对地址通常会发生变化。函数没有 “搬到另一个 Section”，改变的是整份映像的加载基址。实验中不需要记忆任何固定十六进制地址，只需使用 image lookup -n RunSimpleMemoryTest 查看本次运行的结果。

比较地址时应该先判断它属于哪个映像，并结合 image list、image lookup 或 vmmap 获取加载地址，不能把不同运行中的绝对地址直接比较。

这个关系也是符号化（Symbolication）的核心。崩溃日志或 image lookup --address 拿到的都是运行时地址：工具先根据地址落在哪个镜像的加载范围内，确定它属于哪个镜像（崩溃报告的 “Binary Images” 段会记录每个镜像的加载基址），再用该镜像自己的 slide 把运行时地址减回链接地址，最后拿这个链接地址去 dSYM 里查函数名和行号。用错镜像的 slide，或者把不同镜像、不同进程、不同次运行的绝对地址直接比较，都会得到没有意义的结果——这也是为什么调试时要先用 image list 确认加载基址，而不是直接比较两次运行记下的十六进制数。Apple 在 WWDC21 Symbolication: Beyond the basics 中完整演示了 Linker Address、Load Address 与 ASLR Slide 的关系。

#实验：同一个指针变量依次指向三个对象

只观察一次 alloc，虽然能看到 &object 和 object 是两个地址，但还不够直观。下面让同一个指针变量 object 依次保存三个对象的地址：

1
void RunPointerAndObjectTest(void) {
2
    NSObject *firstObject = [[NSObject alloc] init];
3
    NSObject *secondObject = [[NSObject alloc] init];
4
    NSObject *thirdObject = [[NSObject alloc] init];
5

6
    NSObject *object = nil;
7

8
    object = firstObject;
9
    NSLog(@"第 1 次：&object = %p，object = %p",
10
          (void *)&object, (__bridge void *)object); // 断点 1
11

12
    object = secondObject;
13
    NSLog(@"第 2 次：&object = %p，object = %p",
14
          (void *)&object, (__bridge void *)object); // 断点 2
15

16
    object = thirdObject;
17
    NSLog(@"第 3 次：&object = %p，object = %p",
18
          (void *)&object, (__bridge void *)object); // 断点 3
19

20
    // 确保三个对象在整个实验过程中都保持存活，排除地址复用干扰。
21
    NSLog(@"keep alive: %@ %@ %@", firstObject, secondObject, thirdObject);
22
}

在 viewDidLoad 中调用：

1
- (void)viewDidLoad {
2
    [super viewDidLoad];
3
    RunPointerAndObjectTest();
4
}

将工程保持在 Debug、-O0，在标记的三行 NSLog 上分别设置断点。每次暂停都执行：

1
p/x &object
2
p/x object
3
memory region &object
4
memory region object

如果当前 LLDB 版本不能直接解析 memory region object，就先复制 p/x 输出的实际地址，再执行：

1
memory region 0x实际地址

把三次结果记录成下面的表格。不要照抄示例地址，以当次运行结果为准：

由于 firstObject、secondObject、thirdObject 在最后仍会被使用，三个对象在实验期间同时存活，分配器不能把同一块对象内存交给其中两个。因此这个实验应当稳定观察到：

• &object 三次保持不变：它表示局部指针变量 object 自己的地址。在本次 Debug 实验中，它通常位于当前线程栈。
• object 三次保存不同的值：它表示 object 当前保存的对象地址，三次分别指向三个仍然存活的普通对象。
• 两类地址所在 Region 不同：&object 通常落在栈 Region；object 通常落在分配器管理的可写 Region。 已连接的 iPhone 15 上运行 MemoryMapLab，App 启动时连续调用两次实验函数，得到：

1. 在每次函数调用内部，三次赋值中的 &object 都是同一个地址，它表示当前栈帧中指针变量自己的存储位置。
2. 三个对象同时存活时，object 依次保存三个不同地址；三个地址虽然属于同一个分配器 Region，却不是同一块对象内存。
3. &object 位于线程栈 Region，object 保存的对象地址位于另一个分配器 Region，因此 “局部指针变量在栈上” 和 “普通对象本体在堆中” 可以同时成立。

两次函数调用中恰好再次出现相同的 &object，是这次 Debug 构建复用了同一段栈帧位置，不能据此声称局部变量具有静态存储期。三个对象地址在本次运行中呈现相邻分配，也不能据此推导 NSObject 的固定大小或分配器在其他系统版本上的固定策略。

还可以做一个反向实验：去掉 firstObject、secondObject、thirdObject 这些额外强引用，只反复执行 object = [[NSObject alloc] init]。旧对象生命周期结束后，分配器可能复用它的地址。但仅凭地址再次出现，不能精确证明 ARC 在哪一条指令释放了对象；它只能说明对象地址可能被复用，不能用地址大小或是否重复判断对象的新旧。

这正好说明 “指针变量在栈上” 和 “对象在堆上” 可以同时成立。但这句话仍有三个边界：

1. 编译器优化：局部变量可能只存在于寄存器中，或者被完全消除，因此 “局部变量一定在栈上” 不严谨。
2. 字符串字面量：@"Hello" 通常落在主程序的只读映射内，并不是函数每执行一次就在堆上创建一个新字符串对象。
3. Tagged Pointer：部分小型 NSNumber、NSDate、NSString 等值可能直接编码在指针中，并不对应普通堆对象。它属于第二轮实验，本次基础代码暂不加入。

因此，回答 ”对象在哪里” 时，至少需要先确认讨论的是普通动态对象、字面量对象，还是 Tagged Pointer；回答 ”变量在哪里” 时，还要区分变量本身和变量保存的值。

#从 “指针变量与对象本体” 继续追问的面试题

“指针变量不等于对象本体” 不只用于回答对象位于哪里。对象传参、属性访问、ARC、相等性和对象大小等问题，都依赖同一张关系图：

1
指针变量自己的地址：&object
2
        ↓ 这个位置中保存了一个值
3
指针变量保存的值：object
4
        ↓ 普通情况下把它解释成对象地址
5
对象本体：该地址处由运行时和分配器管理的内存

下面按理解顺序梳理常见追问。

1
static void ReplaceObject(NSObject *object) {
2
    object = [[NSObject alloc] init];
3
}
4

5
NSObject *original = [[NSObject alloc] init];
6
ReplaceObject(original);

1
static void ChangePointer(NSMutableString *string) {
2
    string = [NSMutableString stringWithString:@"new"];
3
}
4

5
static void ChangeObject(NSMutableString *string) {
6
    [string appendString:@"!"];
7
}

1
string = anotherString
2
→ 修改局部指针变量保存的地址
3
→ 让它改为指向另一个对象
4

5
[string appendString:@"!"]
6
→ 读取 string 保存的地址
7
→ 找到双方共同指向的对象
8
→ 修改该对象的内部状态

1
NSError *error = nil;
2
BOOL success = [manager loadData:&error];

1
error   的类型：NSError *
2
error   的含义：保存 NSError 对象的地址
3

4
&error  的类型：NSError **
5
&error  的含义：指针变量 error 自己的地址

1
@interface Person : NSObject
2
@property (nonatomic, copy) NSString *name;
3
@end
4

5
- (void)test {
6
    NSString *name = @"Tommy";
7
    self.name = name;
8
}

1
name
2
→ 当前函数中的局部指针变量
3
→ Debug、未优化实验中通常位于栈
4

5
_name
6
→ Person 对象内部的实例变量
7
→ 它的存储跟随 Person 对象本体
8
→ 它保存的仍然是 NSString 对象地址
9

10
self.name
11
→ 属性访问表达式
12
→ 赋值时通常调用 setName:
13
→ 读取时通常调用 name

1
__strong NSObject *strongObject;
2
__weak NSObject *weakObject;

1
NSObject *first = [[NSObject alloc] init];
2
NSObject *second = first;
3

4
first = nil;

1
first = nil
2
→ first 不再指向原对象
3
→ 不等于把对象所在内存直接“擦掉”
4

5
对象是否销毁
6
→ 取决于是否还存在其他 strong 引用

1
NSString *first = [NSString stringWithFormat:@"Tommy"];
2
NSString *second = [NSString stringWithFormat:@"Tommy"];
3

4
BOOL samePointer = (first == second);
5
BOOL equalValue = [first isEqual:second];

1
first == second
2
→ 比较两个指针变量保存的地址
3
→ 判断是否指向同一个对象
4

5
[first isEqual:second]
6
→ 询问对象定义的逻辑相等关系
7
→ 判断两者表示的值是否相等

1
[a isEqual:b] == YES
2
        ↓
3
a.hash == b.hash

1
NSObject *object = [[NSObject alloc] init];
2
NSLog(@"%zu", sizeof(object));

1
sizeof(object)
2
→ 指针变量占多少字节
3

4
class_getInstanceSize([object class])
5
→ 该类的实例布局至少需要多少字节
6

7
malloc_size((__bridge const void *)object)
8
→ 分配器为这个普通堆对象实际提供的分配块有多大

1
指针变量与对象本体
2
        ↓
3
修改指针 vs 修改对象
4
        ↓
5
对象参数传递的是指针值副本
6
        ↓
7
NSError ** 为什么可以写回
8
        ↓
9
self.name、_name、局部 name
10
        ↓
11
strong、weak 与对象生命周期
12
        ↓
13
==、isEqual: 与 hash
14
        ↓
15
copy、集合、Block 与 Tagged Pointer

#两种常见来源：文件映射与匿名内存

从 ”页面内容可以去哪里重新找” 这一角度，VM Region 可以先粗分为两类：

• 文件映射（File-backed Mapping）：内容来自 Mach-O、Framework、dyld shared cache 或通过 mmap 映射的文件。未被修改的页面可以丢弃，需要时再从原文件或系统缓存取得，因此通常更容易保持为 clean。
• 匿名内存（Anonymous Memory）：没有一个可直接重新读取的原始文件，常见于堆、线程栈以及运行时申请的数据。程序真正写入后，相关页面通常成为 dirty；具体怎样计入 Footprint、压缩或回收，留到下一篇讨论。

这不是说” 文件映射永远 clean、匿名内存永远 dirty”。Mach-O 中的可写数据可能通过 Copy-on-Write 形成进程私有页面，文件映射也可能被修改；新申请的匿名地址也可能尚未真正触碰。这里的分类是为了回答内容来源，为系列下一篇的 Clean、Dirty 与 Memory Footprint 建立桥梁，具体的页面状态转换会在那一篇里展开。

#VM Region 的访问权限

调试工具经常用三个字母表示 Region 当前允许的操作：

权限让同一进程中的区域承担不同职责，也贯彻了” 数据不可随意执行、代码不可随意写入” 的安全边界。Apple 在 Investigating memory access crashes 中展示了 r-x 的 __TEXT、rw- 的线程栈以及无权限的 Stack Guard。

把五大分区、来源和权限放到一起，可以得到更接近真实系统的关系：

这一步完成了本文最重要的转换：

1
五大分区告诉我们"用来做什么"
2
        ↓
3
Mach-O、堆和线程栈告诉我们"怎样形成"
4
        ↓
5
VM Region 告诉我们"系统怎样描述"
6
        ↓
7
文件/匿名来源和页面状态继续解释"系统怎样回收与记账"（见系列下一篇）

#iPhone 15 真机实测

为了确认 Simulator 上的结论能否在真实 iOS 环境中复现，我另外建立了一个最小 Objective-C 实验 App MemoryMapLab。真机环境如下：

第一轮启动取得的代表性结果如下：

上表 Tagged Pointer 一行显示为 16 位十六进制（完整 64 位），而其他行是 9~10 位。这不是数据错误：其他行打印的是 ”地址”，数值范围受当前地址空间实际使用量限制；这一行打印的是指针变量的完整位模式本身——因为 Tagged Pointer 不指向任何内存，它的值就是数据编码后直接摆放的结果，所以会占满整个 64 位宽度。

这里最重要的不是记住这些十六进制数，而是观察地址之间的关系：

1. 函数、只读字面量、可写全局数据分别落入 r-x、r--、rw- 的映像 Region；
2. 局部指针变量和它指向的对象本体是两个地址，前者本次位于栈，后者位于分配器管理的区域；
3. 普通对象与 malloc 缓冲区虽然都可归入教学模型中的 “堆”，系统看到的却是分配器管理的 VM Region；
4. Tagged Pointer 的值不是一个可以交给 memory region 查询的普通对象地址。其具体编码属于运行时实现细节，不能依赖本次位模式。

为了验证 ASLR，完全退出并第二次启动同一份二进制，得到以下代表性变化：

主程序中的函数、全局数据和字面量跟随同一个 Mach-O 映像整体移动，权限和相对布局保持一致；栈和堆地址则由线程栈、分配器和当次运行状态分别决定，不能拿它们与 Mach-O 的 slide 做同一种推导。这正是 “ASLR 改变装载基址，但不会把代码突然变成堆内存” 的真机证据。

需要明确数据来源：上表的地址与 Region 是实验 App 通过 vm_region_64 对自身查询后记录的，不是伪装成 LLDB transcript 的输出。要在 Xcode 中独立复核，可以给 MemoryExperimentBreakpoint 添加符号断点；停下后先用 up 回到 RunMemoryExperiment，再执行：

1
frame variable localNumber object localLiteral runtimeValue taggedNumber heapBuffer
2
p/x &globalInitialized
3
p/x &globalZeroInitialized
4
p/x &staticInitialized
5
p/x globalStringLiteral
6
memory region &globalInitialized
7
memory region heapBuffer

#iPhone 15 真机实验：地址空间有多大，真正可用多少

Size Matters 根据 2022 年公开的 XNU 源码讨论了 iOS 设备的虚拟地址空间、可用地址空间和 Extended Virtual Addressing。但文章中的设备表格、XNU 版本和 “扩展到 64 GB” 都是当时的结果，不能直接当作今天所有设备的固定结论。这里继续使用 MemoryMapLab，在当前 iPhone 15 上重新测量。

实验前先分清五个容易混在一起的数字：

1
#import <mach/mach.h>
2
#import <unistd.h>
3

4
static kern_return_t ProbeOnePage(vm_address_t requestedAddress) {
5
    vm_size_t pageSize = (vm_size_t)sysconf(_SC_PAGESIZE);
6
    vm_address_t address = requestedAddress;
7

8
    kern_return_t result = vm_allocate(
9
        mach_task_self(),
10
        &address,
11
        pageSize,
12
        VM_FLAGS_FIXED
13
    );
14

15
    if (result == KERN_SUCCESS) {
16
        // 不读、不写，立即释放；这里只验证虚拟地址能否被保留。
17
        vm_deallocate(mach_task_self(), address, pageSize);
18
    }
19
    return result;
20
}
21

22
static BOOL ReserveAndRelease(vm_size_t size, vm_address_t *resultAddress) {
23
    vm_address_t address = 0;
24
    kern_return_t result = vm_allocate(
25
        mach_task_self(),
26
        &address,
27
        size,
28
        VM_FLAGS_ANYWHERE
29
    );
30

31
    if (result != KERN_SUCCESS) {
32
        return NO;
33
    }
34

35
    if (resultAddress != NULL) {
36
        *resultAddress = address;
37
    }
38
    vm_deallocate(mach_task_self(), address, size);
39
    return YES;
40
}

1
指针宽度：64 bit
2
    ≠ App 拥有 2^64 字节可用空间
3

4
SDK 公开 CPU 上界：63 GiB
5
    ≠ 当前普通 task 的实际上界
6

7
当前普通 task 上界：17.375 GiB
8
    ≠ 17.375 GiB 全部可供堆使用
9

10
当前最大连续空洞：约 5.375 GiB
11
    ≠ App 可以安全写入 5.375 GiB 物理内存

#从单个地址扩展

LLDB 适合追踪 ”这个地址是什么”，vmmap 更适合回答 ”整个进程有哪些 Region”。对运行中的调试进程或导出的 Memgraph，可以从下面的命令开始：

1
vmmap -summary 12345
2
vmmap /path/to/App.memgraph

Xcode 与 Instruments 中几个常见工具关注的问题并不相同：

结合本次实验，可以先画出一张不强调高低地址顺序的内存地图：

1
MemoryMapExperiment 进程的虚拟地址空间
2
├── 主程序代码映射：Mach-O __TEXT / __text，r-x
3
├── 主程序只读数据：字符串、__DATA_CONST 等，r--
4
├── 主程序可写数据：全局变量、静态变量，rw-
5
├── 动态分配区域：普通对象、malloc buffer，rw-
6
├── 主线程栈：局部状态，rw-
7
├── 后台线程栈：局部状态，rw-
8
├── Framework 与 dyld shared cache：代码和数据映射
9
└── 其他 VM Region：匿名映射、mmap 文件、Guard 等

#官方资料

• Apple — About the Virtual Memory System
• Apple — Overview of the Mach-O Executable Format
• Apple — Viewing Virtual Memory Usage
• Apple — Investigating memory access crashes
• Apple — Reducing your app’s launch time
• WWDC21 — Symbolication: Beyond the basics
• Apple Kernel Programming Guide — Memory and Virtual Memory
• Apple — Extended Virtual Addressing Entitlement
• Apple Open Source XNU — arm64 VM parameters
• Apple — Working with Objects
• Apple — Object Ownership
• Apple — NSObjectProtocol isEqual:
• Clang — Objective-C Automatic Reference Counting
• LLDB — GDB to LLDB command map
• LLDB — Symbolication

#操作系统资料

• 小林 Coding — 图解操作系统
• 小林 Coding — 为什么要有虚拟内存？
• 小林 Coding — malloc 是如何分配内存的？

#iOS 与 Objective-C 延伸

• Size Matters: An Exploration of Virtual Memory on iOS
• Mike Ash — Stack and Heap Objects in Objective-C
• Mike Ash — Intro to the Objective-C Runtime
• 本站译文 — Stack and Heap Objects in Objective-C