iOS 中的虚拟内存 (理解为什么需要虚拟内存)
什么叫“虚拟地址空间”？
一句话：它是 CPU 看得见、App 以为自己独享，但实际上会被内核和硬件（MMU）动态翻译到真实 物理内存 的一整块“虚拟地图”。
1. 背景：为什么要“虚拟”？
| 需求 | 虚拟地址空间能做什么 |
|---|---|
| 进程隔离 | 给每个进程各分一套 0 → N 的地址，互不重叠，进程 A 读不到进程 B 的数据。 |
| 内存保护 | 页级读/写/执行权限由页表标记；越界访问马上抛 EXC_BAD_ACCESS。 |
| 弹性分配 | 物理内存碎片化无关紧要，只要虚拟地址连续即可（“看上去一整块”）。 |
| 高级特性 | Copy‑on‑Write、内存映射文件 (mmap)、共享库复用、ASLR、PAC … |
2. 在 iOS/arm64 上怎么实现？
2.1 MMU + 页表
- MMU（Memory Management Unit）：CPU 访存时，把 64‑bit 虚拟地址 拆成多级索引，通过页表（
TTBR0/TTBR1指向）翻译成 48‑bit 物理地址。 - 页大小：iOS 全系 16 KiB；一页是虚拟空间管理的基本粒度。
- 属性位：每个页表条目有 RWX 标志、用户/内核态位、内存类型（缓存/设备）等。
2.2 用户态 vs 内核态
| 区域 | arm64 虚拟高位 | 典型范围 (48‑bit VA) | 说明 |
|---|---|---|---|
| 用户空间 | [0, 0x0000_FFFF_FFFF] | 0 → 128 TiB | 每个进程独占；App 代码、堆、栈、JIT、dyld shared cache… |
| 内核空间 | [0xFFFF_0000_0000_0000, 2⁶⁴) | 顶部 128 TiB | 所有进程共享同一内核映像与数据；受 KTRR/PACDMA 保护 |
- 两块空间由 异常级别（EL0 / EL1） 与
TTBR的切换隔离：App 只能使用下半部地址，高位一旦访问就触发权限异常。 - 高位还用到 Top‑Byte‑Ignore (TBI)：高 8 bit 可存自定义 tag（例如 Swift 的指针压缩、MTE 内存标记等）。
3. 64‑bit 设备典型虚拟地址布局（示意）
0x0000_0000_0000_0000
│ 保留页 (NULL, guard)
├─ Mach-O 主可执行 (PIE, text+data)
├─ __DATA_CONST / 读取‑仅映射
├─ Heap ⇡ 动态增长
│
│ (空洞，可供 mmap / JIT / stack 使用)
│
├─ Thread #N Stack ⇣ 向下增长
│ └─ Guard Page (不可访问)
│
├─ dyld shared cache (私有或共享段)
└─ … (高地址)
0x0000_FFFF_FFFF_FFFF ← 用户空间顶
───────────────────────
0xFFFF_0000_0000_0000 ← 内核空间起
├─ Kernel Mach‑O + KEXT (KASLR)
└─ I/O 映射、vmalloc、kstack…
0xFFFF_FFFF_FFFF_FFFF ← 64‑bit 顶
每次 App 启动、设备冷启动 时，这些段会因为 ASLR 被整体“滑动”（加上 slide 值），但相对排列不变。
4. 与开发者相关的日常场景
| 你在做什么 | 虚拟地址空间发生了什么 |
|---|---|
使用 malloc | 内核在“堆区”后方找一块尚未用过的虚拟页，映射物理内存并返回 虚拟指针。 |
| 调试崩溃日志 | 0x104a74000 这样的指针是“已经加了 slide 的虚拟地址”；需要减去 slide 才能对应符号表。 |
| 开启 JIT / Metal | 虚拟页被标记为可执行或设备内存，MMU 读到属性位后，用不同缓存策略访问。 |
| 访问空指针 / 越界 | 目标虚拟页没有映射或权限位不匹配 → MMU 触发 Page Fault，内核抛异常。 |
5. 小结
- 虚拟地址空间 = “给每个进程画的一张 私有地图”；
- MMU + 页表 做“坐标翻译”与“边界安检”；
- iOS 在这张地图上再叠加 ASLR、PAC、KTRR、代码签名 等多重防护。
借助虚拟地址空间，iOS 既能让每个 App 看到一个 连续、干净且安全 的内存世界，也能让内核在背后高效地管理、隔离、复用有限的物理内存资源。