写时拷贝
在数据第一次写入到某个存储位置时，首先将原有内容拷贝出来，写到另一位置处，然后再将数据写入到存储设备中，该技术只拷贝在拷贝初始化开始之后修改过的数据。
linux中的cow
在Linux程序中，fork（）会产生一个和父进程完全相同的子进程，但子进程在此后多会exec系统调用，出于效率考虑，linux中引入了“写时复制“技术，{% span blue, 也就是只有进程空间的各段的内容要发生变化时，才会将父进程的内容复制一份给子进程。%}
在fork之后exec之前两个进程用的是相同的物理空间（内存区），子进程的代码段、数据段、堆栈都是指向父进程的物理空间，也就是说，两者的虚拟空间不同，但其对应的物理空间是同一个。当父子进程中有更改相应段的行为发生时，再为子进程相应的段分配物理空间，如果不是因为exec，内核会给子进程的数据段、堆栈段分配相应的物理空间（至此两者有各自的进程空间，互不影响），而代码段继续共享父进程的物理空间（两者的代码完全相同）。而如果是因为exec，由于两者执行的代码不同，子进程的代码段也会分配单独的物理空间。
在网上看到还有个细节问题就是，fork之后内核会通过将子进程放在队列的前面，以让子进程先执行，以免父进程执行导致写时复制，而后子进程执行exec系统调用，因无意义的复制而造成效率的下降。
cow思想
当一个父进程fork子进程之后，如果要完全复制出来一份内存，需要消耗很多额外的资源（内存等），而子进程又并不一定会去使用或者修改这些数据，或者仅仅使用一部分和修改一部分。
于是copy on write就被设计了出来，相当于把复制的过程延后到了修改时触发。这解决了2个问题：
- 立刻复制带来的性能问题。（如果某个应用使用了十几G的内存，立刻复制会消耗不少性能）
- 无法复制的问题。（如果物理机上某个进程使用了一半以上的内存，那就没有空间进行复制了）
应用
cow技术被用在很多地方，这里举几个常见的。
在中间件中维护读多写少变量
在微服务中，服务提供者会向注册中心注册，服务消费者会监听注册中心的事件来更新本地可用服务列表，而这个列表就是一个读多写少的变量。
如果使用读写锁来控制并发，那每次读取数据时都会加读锁，在量比较大的情况下，性能消耗也是不可忽视的。另外在有服务上下线时，需要进行获取写锁，排除所有读操作，会造成服务短暂的不可用。
在java中就有类似的工具类提供这样的支持：CopyOnWriteArrayList等
redis中的RDB持久化
redis在采用RDB方式持久化时，会先fork出一个子进程，由于子进程拥有父进程的内存快照，所以可以慢慢将所有数据写入磁盘。并且此时redis依旧可以对外提供读写服务。
如果中间有写入缓存命令，那redis（父进程）会把需要修改的数据复制出来一份再做修改。{% span blue, 事实上这个过程由系统fork机制完成的，这也是为什么redis在RDB时采用子进程而不是子线程来完成持久化的原因 %}
由此也可以看出，cow设计大量出现在快照功能模块中。
思想
cow体现了一种计算机优化思想，那就是通过推迟真正的触发时间来提高效率。类似的优化方式也有不少，例如懒加载等等。
本站由
