python多进程fork默认启用写时复制（cow），父子进程初始共享物理内存页，仅在写入时复制；只读大对象几乎零额外开销，但可变对象修改、引用计数变更、gc或打印等均可能触发复制。
Python多进程启动时，默认采用 fork 方式（在 Unix/Linux/macOS 上），此时子进程会继承父进程的整个内存空间，但并非立即复制全部数据——而是依赖操作系统的 写时复制（Copy-on-Write, CoW） 机制。理解这一点，是优化多进程内存使用、避免意外内存暴涨的关键。
写时复制如何工作？
fork 后，父子进程的虚拟内存页表指向相同的物理内存页，内核将这些页标记为只读。只要父子双方都只读取数据，就不会发生实际复制；一旦某一方尝试修改某页内存（比如给一个列表 append 元素、给字典赋新值），内核捕获到写保护异常，才为该页分配新物理内存并复制内容，再允许写入。
这意味着：
- 只读的大对象（如预加载的模型参数、大型只读 NumPy 数组、JSON 配置字典）几乎不增加额外内存开销；
- 看似“共享”的变量，一旦被任一进程修改，就会触发独立副本，内存占用翻倍甚至更高（尤其频繁修改时）；
- CoW 是操作系统级行为，Python 解释器本身不参与控制，也无法主动“取消”或“强制触发”复制。
哪些操作容易意外触发写时复制？
表面上没变，实则已写入的常见情况包括：
立即学习“Python免费学习笔记（深入）”；
-
可变对象的就地修改：例如
data_list.append(x)、cache_dict[key] = value、arr[0] = 1（NumPy 数组）； - 隐式引用计数变更：CPython 中对对象增减引用（如局部变量赋值、函数传参）虽不改内容，但会修改对象头中的 refcount 字段——该字段位于对象所在内存页内，可能触发整页复制；
- GC 相关操作：子进程中首次触发垃圾回收，可能遍历并临时标记对象，导致部分页被写入；
-
日志/调试输出：打印大对象（如
print(big_dict)）会触发对象遍历与字符串化，间接引起引用变化或缓冲区写入。
如何减少不必要的内存复制？
核心思路是：让子进程尽量只读、延迟写、隔离写、用共享内存替代。
-
用
tuple、frozen_set或types.MappingProxyType替代可变容器，明确表达只读意图，也能防止误改； -
避免在子进程中修改从父进程继承的大型数据结构；需修改时，显式创建副本（如
local_data = copy.deepcopy(shared_data)），反而更可控； -
用
multiprocessing.shared_memory（Python 3.8+）或multiprocessing.Array/Value管理真正需要跨进程读写的原始数据，它们驻留在共享内存段，不走 CoW 路径； -
启动子进程前，主动释放父进程中无用的大对象（如
del big_data+gc.collect()），确保 fork 时内存页更干净； -
在 macOS 或 Windows 上注意差异：macOS 的 fork CoW 行为与 Linux 接近；Windows 不支持 fork，
multiprocessing默认用 spawn，会重新导入模块、重建对象，天然无 CoW，但启动慢、全局状态不继承。
验证是否发生了写时复制？
可通过监控进程 RSS 内存变化粗略判断：
- 启动子进程后立即检查
psutil.Process().memory_info().rss，应接近父进程； - 子进程执行一次大对象修改（如向百万元素列表追加）后再查 RSS，若显著增长（如 +100MB），说明相关页已被复制；
- 更精确的方法是分析
/proc/[pid]/smaps（Linux）中Pss和Shared_Clean字段，但需 root 权限且较复杂。
写时复制不是 Python 特性，而是 fork + 操作系统内存管理的协同结果。它让多进程“看起来轻量”，但也埋下隐性开销。清楚它的触发边界，才能写出内存友好的并发程序。不复杂但容易忽略。
