fork()后父子进程共享物理页帧，页表项标记为只读；仅当父进程写入时触发cow复制新页，子进程纯读不触发。
fork()之后，父子进程的内存页到底共享什么
子进程不是复制了父进程的全部物理内存，而是只复制页表（page table），所有内存页的页表项被标记为只读。此时父子进程的虚拟地址映射到同一块物理内存，但任何写操作都会触发内核干预——这正是COW生效的前提。
常见错误现象：top 或 ps 显示 Redis 进程内存占用瞬间翻倍，其实是误判：COW 未发生前，RES（常驻内存）不会增长；只有父进程真正修改某页时，内核才分配新物理页并复制内容，这时才体现为内存上升。
- 共享的是物理页帧（page frame），不是虚拟地址空间
- 代码段、只读数据段几乎永远不触发 COW
- Redis 的键值数据集中在堆和 Redis 自定义数据结构中，这些区域最常被写入，也最易触发 COW
- 子进程对内存页只有只读访问权限，无法主动触发 COW —— 只有父进程的写操作才会触发
为什么是父进程写导致复制，而不是子进程读
COW 的“写”特指**可写页上的写入动作**。子进程在 RDB 遍历过程中只是读取内存页，CPU 不会报缺页异常，内核也不会介入。而父进程执行 SET、HSET 等命令时，试图修改一个被标记为只读的页，CPU 检测到保护位后触发缺页异常（page fault），内核接管并完成三步：分配新物理页 → 复制原页内容 → 更新父进程页表指向新页。
容易踩的坑：有人以为“子进程在读，所以要复制”，这是混淆了 COW 和普通内存拷贝。子进程不需要复制，它本来就能安全读取 fork 时刻的原始页；真正需要隔离的是父进程后续的修改行为。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 子进程生命周期内从不写内存（RDB 是纯读操作），所以永远不会触发 COW
- 父进程每修改一个已被共享的页，就多分配一页物理内存
- 如果父进程修改非常频繁（如高吞吐写入场景），COW 开销可能显著升高，表现为内存使用率陡增甚至 OOM
RDB 文件里保存的是哪一刻的数据
RDB 快照反映的是 fork() 系统调用返回成功的那个精确时间点的内存状态，不是 BGSAVE 命令发出时，也不是 RDB 写完时。哪怕快照耗时 5 秒，期间父进程改了 10 万次 key，子进程看到的仍是 fork 那一刻的完整视图。
验证方式很简单：启动 Redis 后立刻 SET keyA "v1"，紧接着 BGSAVE，然后马上 SET keyA "v2"。等 RDB 完成，停掉 Redis 并用 redis-check-rdb dump.rdb 查看，keyA 的值一定是 "v1"。
- 时间点锚定在
fork()返回，不是命令入口或磁盘落盘完成 - 该机制天然保证快照一致性，无需加锁或暂停写入
- 注意：如果 fork 耗时过长（如内存上百 GB），主进程会卡在系统调用里，这属于 OS 层限制，和 COW 无关
实际部署中哪些配置会影响 COW 表现
COW 本身由内核控制，Redis 不直接配置它，但以下参数会间接放大或缓解其影响：
-
save 60 10000触发更频繁的bgsave，意味着更多 fork + 更多潜在 COW 峰值，尤其在写密集型业务中容易引发内存抖动 -
stop-writes-on-bgsave-error yes能防止因 fork 失败（如Cannot allocate memory）导致后台持久化静默失效 -
vm.overcommit_memory = 1（Linux 内核参数）允许 fork 分配“虚拟”内存，避免因内存不足直接拒绝 fork，是生产环境强烈建议开启的选项 - 关闭
rdbcompression yes会略微降低子进程 CPU 压力，但不影响 COW 内存行为；压缩本身发生在页读取之后，不改变页复制时机
COW 不是 Redis 的“特性”，它是 Linux fork 的通用行为。理解这一点，才能分清问题归属：内存暴涨若发生在 fork 后几秒内，大概率是业务写入模式 + 物理内存余量不足共同导致，不是 Redis 有 bug，也不是配置写错了。
