1
1. 进程隔离
2
   进程 A 的虚拟地址 0x400000 和进程 B 的 0x400000
3
   映射到不同的物理页 → 互不干扰，一个崩了不影响另一个
4

5
2. 内存超售 (Overcommit)
6
   10 个进程各 malloc 1GB = 10GB 虚拟内存
7
   但物理内存只有 8GB？没问题！
8
   → OS 保证分配虚拟页（页表项标记 not present）
9
   → 真正写入时才分配物理页（按需分配 = demand paging）
10
   → 大部分页可能永远不被访问
11

12
3. 共享内存
13
   多个进程加载同一个 libc.so → 只需要在物理内存中存一份
14
   每个进程的页表都映射到相同的物理页（共享映射）
15

16
4. 权限保护
17
   代码段 → 只读+可执行（不可写 → 防止代码注入）
18
   栈 → 可读写+不可执行（NX bit → 防止栈溢出攻击）
19
   内核空间 → 用户态不可访问（Ring 0 vs Ring 3）

1
多级页表的核心思想：只为实际使用的地址空间创建页表。
2

3
以两级页表为例（32 位）：
4
┌────────────┬────────────┬────────────┐
5
│ 一级索引 10位│ 二级索引 10位│  偏移 12位   │
6
└────────────┴────────────┴────────────┘
7

8
一级页表（Page Directory）：1024 个条目 → 4KB
9
每个条目指向一个二级页表（如果那段地址被使用了的话）
10

11
如果进程只用了 12MB 的地址空间（3 个一级条目）：
12
- 一级页表：4KB（始终存在）
13
- 二级页表：3 × 4KB = 12KB（只为使用的部分创建）
14
- 总计：16KB ← 远小于单级页表的 4MB！
15

16
x86-64 用四级页表，原理相同，只是层数更多。

1
x86-64 的页表项（Page Table Entry）= 8 字节 = 64 位
2

3
┌─────────────────────────────────────────────────┐
4
│ [63]    NX (No Execute)     → 该页不可执行      │
5
│ [62:52] 保留/软件使用位                           │
6
│ [51:12] 物理页帧号 (PFN)    → 物理地址的高位      │
7
│ [11:9]  可用位              → OS 自定义使用       │
8
│ [8]     G (Global)          → TLB 不随 CR3 刷新  │
9
│ [7]     PS (Page Size)      → 大页标志           │
10
│ [6]     D (Dirty)           → 该页被写过         │
11
│ [5]     A (Accessed)        → 该页被访问过       │
12
│ [4]     PCD (Cache Disable) → 禁用缓存           │
13
│ [3]     PWT (Write Through) → 写穿策略           │
14
│ [2]     U/S (User/Supervisor) → 用户态可访问？   │
15
│ [1]     R/W (Read/Write)    → 可写？             │
16
│ [0]     P (Present)         → 该页在物理内存中？  │
17
└─────────────────────────────────────────────────┘
18

19
面试重点标志位：
20
P  = 0 → 页不在内存 → 访问时触发 Page Fault
21
R/W    → 控制只读/可写（COW 用这个位实现）
22
U/S    → 控制用户态是否可访问（内核隔离）
23
D      → 脏页标记（换出时需要写回磁盘）
24
A      → 访问标记（Clock 算法用这个位）
25
NX     → 不可执行（防止 shellcode 攻击）

1
普通页 4KB → TLB 一条覆盖 4KB
2
大页 2MB   → TLB 一条覆盖 2MB (= 512 个普通页)
3
巨页 1GB   → TLB 一条覆盖 1GB
4

5
好处：
6
- TLB 条目数不变，但覆盖的地址范围增大 512/262144 倍
7
- 大幅减少 TLB miss
8
- 减少 Page Walk 的次数（大页只需两/三级查找）
9

10
代价：
11
- 内部碎片增大（分配 2MB，可能只用几 KB）
12
- 内存分配灵活性降低
13

14
适用场景：
15
- 数据库（Oracle/MySQL 推荐开启大页）
16
- 游戏服务器（大量连续内存访问）
17
- JVM 堆（大块连续内存）
18

19
Linux：
20
  echo 1024 > /proc/sys/vm/nr_hugepages  # 预分配 1024 个 2MB 大页
21
  或使用 Transparent Huge Pages (THP) 自动合并

1
Clock 算法是 LRU 的低开销近似：
2

3
原理：
4
1. 所有页帧围成一个环形（clock face）
5
2. 每个页有一个 Accessed 位（硬件自动设置）
6
3. 时钟指针从上次停的位置开始扫描
7

8
页面置换时：
9
→ 检查指针指向的页
10
  if (Accessed == 1)：
11
    Accessed = 0（给第二次机会）
12
    指针前进
13
  if (Accessed == 0)：
14
    换出这个页！
15
    指针停在下一位
16

17
直觉：最近被访问过的页会有 Accessed=1 → 得到保留
18
      长时间没被访问的页 Accessed=0 → 被换出
19
      效果接近 LRU，但只需要一个位（O(1)空间）

1
mmap vs read 的对比：
2

3
read():
4
1. 用户调用 read() 系统调用
5
2. 内核从磁盘读数据到 Page Cache（内核缓冲区）
6
3. 内核把 Page Cache 的数据拷贝到用户缓冲区
7
→ 数据在内存中存了两份：Page Cache + 用户缓冲区
8

9
mmap():
10
1. 用户调用 mmap()，OS 建立虚拟地址到文件的映射
11
2. 首次访问时 Page Fault → OS 从磁盘读入 Page Cache
12
3. 用户直接访问 Page Cache（页表直接映射到 Page Cache 的物理页）
13
→ 数据只在内存中存一份！零拷贝！
14

15
适用场景：大文件的随机读取（如游戏资源包）

1
ptmalloc2 的核心概念：
2

3
Arena（分配区）：每个线程有自己的 arena → 减少锁竞争
4
  主 arena: 使用 brk() 扩展
5
  非主 arena: 使用 mmap() 分配
6

7
Chunk（内存块）：malloc 返回的每块内存前面有 header
8
  ┌─────────────────────────────────┐
9
  │ prev_size (8B) │ size (8B)      │ ← chunk header
10
  │ flags: P(前块在用) M(mmap) A    │
11
  ├─────────────────────────────────┤
12
  │           用户数据               │ ← malloc 返回的指针指向这里
13
  │           ...                   │
14
  └─────────────────────────────────┘
15

16
Bin（空闲链表）：按大小分组的空闲 chunk 链表
17
  Fast Bins:     16~80 字节，LIFO，不合并（极速分配）
18
  Small Bins:    < 512 字节，FIFO，排序
19
  Large Bins:    >= 512 字节，按大小排序
20
  Unsorted Bin:  刚释放的 chunk 先放这里，稍后整理

1
ptmalloc2 的问题：
2
- 多线程场景下 arena 锁竞争（非主 arena 数量有限）
3
- 内存碎片较严重
4
- free 后的内存不容易归还 OS
5

6
tcmalloc (Google) / jemalloc (Facebook/FreeBSD) 的核心优化：
7

8
1. Thread-Local Cache（线程本地缓存）
9
   每个线程有自己的小对象缓存 → 分配/释放完全无锁！
10
   只有缓存耗尽时才需要加锁从全局取
11

12
2. Size Class（大小分类）
13
   把分配大小归类到固定的 size class（如 8, 16, 32, 48, 64...）
14
   减少碎片 + 加速查找
15

16
3. 页级管理（span/slab）
17
   批量从 OS 获取页面，按 size class 切割
18

19
性能对比（多线程场景）：
20
ptmalloc2:  可能有锁竞争 → 多线程不稳定
21
tcmalloc:   TLC 无锁快速路径 → ~10-20ns/次
22
jemalloc:   类似 tcmalloc + 更好的碎片控制

1
UE5 的默认分配器 FMallocBinned2：
2

3
1. Size Class 分桶（类似 tcmalloc）
4
   小对象：按 16B 步进→ 16, 32, 48, 64, ..., 256B
5
   中对象：按更大步进→ 288, 320, ..., 4KB
6
   大对象：直接走 OS 的 VirtualAlloc/mmap
7

8
2. 每个线程有自己的缓存（Thread-Local）
9
   分配/释放热路径无锁
10

11
3. Pool 组织
12
   每个 size class 有一组 64KB 的 pool
13
   pool 内用位图(bitmap)管理空闲 slot → O(1) 分配
14

15
4. 虚拟内存预留
16
   启动时预留大块虚拟内存（Reserve）
17
   按需提交物理页（Commit）
18
   → 避免碎片，地址空间连续

1
移动端游戏的内存限制：
2

3
iOS:  超过设备内存的一定比例 → 系统直接杀进程（没有 swap！）
4
      iPhone 15: ~6GB 物理内存，游戏通常限制 ~1.5-2GB
5

6
Android: 有 zRAM（压缩内存）和 swap，但超限也会被 LMK 杀掉
7
      低端机可能只有 2-3GB，游戏限制 ~800MB-1GB
8

9
主机/PC: 限制宽松但仍需管理
10
      PS5: 16GB GDDR6（CPU+GPU 共享）
11
      实际可用约 12GB
12

13
游戏引擎的内存预算系统：
14
├── 纹理预算:     ~500MB (最大的部分)
15
├── 网格/模型:    ~200MB
16
├── 音频:         ~100MB
17
├── 动画:         ~50MB
18
├── 脚本/代码:    ~100MB
19
├── 物理:         ~50MB
20
├── UI:           ~50MB
21
└── 系统/引擎:    ~200MB
22
    总计:         ~1.25GB
23

24
每个系统有预算上限 → 超出时触发 LOD 降级 / 资源卸载

1
// 纹理流式加载的简化原理
2
class TextureStreamer {
3
    struct TextureLevel {
4
        void* mapped_data;    // mmap 映射的数据
5
        size_t offset;        // 在 PAK 文件中的偏移
6
        size_t size;          // 该 mip 级别的大小
7
        bool resident;        // 是否已加载到 GPU
8
    };
9

10
    int _pak_fd;              // 资源包文件描述符
11

12
public:
13
    // 流式加载某个 mip 级别
14
    void streamIn(Texture& tex, int mip_level) {
15
        auto& level = tex.levels[mip_level];
16

17
        // mmap 该 mip 级别的数据（不立即读入内存！）
18
        level.mapped_data = mmap(
19
            nullptr, level.size,
20
            PROT_READ, MAP_PRIVATE,
21
            _pak_fd, level.offset
22
        );
23

24
        // 上传到 GPU（此时才真正从磁盘读取 → Page Fault → OS 异步读入）
25
        uploadToGPU(level.mapped_data, level.size, mip_level);
26
        level.resident = true;
27

28
        // 上传完成后可以 munmap（GPU 已经有数据了）
29
        munmap(level.mapped_data, level.size);
30
    }
31

32
    // 卸载不需要的 mip 级别（释放 GPU 内存）
33
    void streamOut(Texture& tex, int mip_level) {
34
        freeGPUMemory(tex, mip_level);
35
        tex.levels[mip_level].resident = false;
36
    }
37
};

1
LOD (Level of Detail) 策略：
2

3
         近距离         中距离           远距离
4
纹理:   4096×4096      1024×1024       256×256
5
        (mip 0)        (mip 2)         (mip 4)
6
        64MB           4MB             256KB
7

8
模型:   10000 三角面    2000 三角面     200 三角面
9

10
常驻内存（永远不卸载）：
11
- 低 mip 级别的纹理（远处看到的，体积小）
12
- 玩家角色的高精度模型
13

14
按需加载（接近时才加载）：
15
- 高 mip 级别的纹理（近处看到的，体积大）
16
- 远处物体的高精度模型
17

18
优先卸载（远离后立刻卸载）：
19
- 之前位置的高精度资源