从第一性原理理解写时复制COW

写时复制（Copy-on-Write，COW）是 Linux 进程创建和内存管理的核心机制，理解它得先搞清楚进程创建时面临的根本矛盾是什么。（这也是 Zygote 的底层核心原理，同时也是 Flutter 单 SO 优化方案背后的依仗。）

第一性：进程创建面临什么根本矛盾

如果没有 COW，会是什么样子？

父进程（1GB 内存）
    │
    ▼ fork()
子进程（1GB 内存）── 完全独立的 1GB 物理内存
结果：2GB 物理内存被占用，但内容一模一样

本质：延迟复制 + 共享只读

COW 的思想其实极其简单：

┌─────────────────────────────────────────┐
│           父进程虚拟地址空间              │
│  ┌─────────┐  ┌─────────┐  ┌─────────┐ │
│  │  页 A   │  │  页 B   │  │  页 C   │ │
│  └────┬────┘  └────┬────┘  └────┬────┘ │
└───────┼────────────┼────────────┼──────┘
        │            │            │
        ▼            ▼            ▼
┌─────────────────────────────────────────┐
│              页表（复制）                │
│  ┌─────────┐  ┌─────────┐  ┌─────────┐ │
│  │ 映射关系 │  │ 映射关系 │  │ 映射关系 │ │
│  └────┬────┘  └────┬────┘  └────┬────┘ │
└───────┼────────────┼────────────┼──────┘
        │            │            │
        └────────────┴────────────┘
                      │
                      ▼
        ┌─────────────────────────┐
        │    物理内存（共享）      │
        │  ┌─────┐┌─────┐┌─────┐ │
        │  │ 页A ││ 页B ││ 页C │ │ ◄── 只读，标记为共享
        │  └─────┘└─────┘└─────┘ │
        └─────────────────────────┘

fork 瞬间发生了什么？

• 虚拟地址空间：复制了（页表复制）
• 物理内存：没有复制，父子指向同一块物理页
• 页表权限：标记为只读

写时复制触发过程

步骤 1：fork 完成
父进程 ──► 共享物理页 ◄── 子进程
            （只读标记）

步骤 2：子进程尝试修改页 B
        │
        ▼ 触发页错误（Page Fault）
        因为页 B 是只读的，但子进程要写入
        │
        ▼ 操作系统介入
        1. 分配新的物理页 B'
        2. 把原页 B 的内容复制到 B'
        3. 子进程的页表指向 B'（可写）
        4. 父进程的页表仍指向 B（可写）

步骤 3：结果
父进程 ──► 页A ──► 物理页A（共享）
        ──► 页B ──► 物理页B（独有）
子进程 ──► 页A ──► 物理页A（共享）
        ──► 页B ──► 物理页B'（独有，刚复制）

解决的问题

核心场景

1. fork() 创建进程（最典型的场景）

// Linux 中 fork 的 COW 实现
pid_t pid = fork();
if (pid == 0) {
    // 子进程
    // 此时和父进程共享所有物理页
    *ptr = 100;  // 修改这一页时才触发复制
}

效果：

• 一个 1GB 的进程 fork 后，如果不修改任何数据，物理内存只增加几 KB（页表开销）
• 修改 10% 的数据，物理内存只增加 100MB

2. 文件映射（mmap）

// 多个进程 mmap 同一个文件
void* addr1 = mmap(NULL, size, PROT_READ, MAP_SHARED, fd, 0);
void* addr2 = mmap(NULL, size, PROT_READ, MAP_SHARED, fd, 0);

效果：

• 两个进程共享同一份文件内容的物理页
• 都不修改：内存中只有一份
• 某个进程修改（MAP_PRIVATE）：触发 COW，复制一份给修改者

3. Android Zygote（我们刚聊的）

Zygote 预加载 Framework（只读）
    │
    ▼ fork 出微信
    共享 Framework 物理页
    │
    ▼ 微信加载自己的代码
    修改自己的页，不影响 Zygote 和其他 App

效果：

• 100 个 App 共享同一份 Framework 内存
• 物理内存节省数百 MB

4. 字符串/数据结构 copy（编程语言层面）

// C++ std::string 的 COW 实现（C++11 前常见）
std::string s1 = "hello world";  // 分配内存
std::string s2 = s1;             // 不复制，共享引用计数
s2[0] = 'H';  // 此时才触发 COW，复制一份给 s2

注意： C++11 后 string 不再用 COW（因为多线程问题），但其他数据结构仍可用。

为什么 COW 能工作：基于一个关键假设

如果这个假设不成立——比如 fork 后子进程立即修改所有页，COW 反而更慢：

• 正常复制：一次性 memcpy，缓存友好
• COW：逐页触发页错误，逐页复制，缺页中断开销叠加

所以 COW 不是万能优化，它的收益取决于“共享后修改的比例”。

一句话总结

具体总结