fork调用后，子进程与父进程是否共享变量

回顾fork调用 
fork系统调用从已存在的进程中生成一个新的进程，这个新的进程就是子进程，我们可以通过fork系统调用的返回值来区分子进程还是父进程。 
一个进程，包括代码、数据和分配给进程的资源。fork（）函数通过系统调用创建一个与原来进程几乎完全相同的进程。 
我们的问题是，进程中的变量是否由父进程和子进程共享？ 
背景 
最开始我简单的认为，似乎是看视频里说的。对于只读变量，父进程和子进程是共享的。对于进行写操作的变量，父进程和子进程是独立。后来在自己做实验是发现这样一个现象，于是就进行了思考。如图所示 
这是代码

#include<stdio.h>
#include<sys/types.h>
#include<sys/stat.h>
#include<unistd.h>
int main(){
    pid_t pid;
    int num=0;
    pid=fork();
    if(pid==0){
        num+=10;
        printf("child %d\n",num);
        printf("child %d\n",&num);
    }
    if(pid>0){
        num+=20;
        printf("parent %d\n",num);
        printf("parent %d\n",&num);
    }

    return 0;
}

这是运行结果

parent 20
parent -948260088
child 10
child -948260088

 

分析 
由于num在子进程中加上了10，结果为10，父进程中加上了20，结果为20.所以num这个变量对于父进程和子进程来说应该是独立的。 
但是看两个进程中的num的地址，发现居然是一样的，这就有点奇怪了，难道父子进程中的num变量是共享的么。可这和之前的解释是相互矛盾的。 
仔细想一想后 
一个程序中代码中的变量要么是事先声明好的，要么是动态分配的，在这里num显然是事先分配好的变量，也就是说，num在声明时其地址就已经确定就好了。我们的num变量是在fork调用前定义的。所以无论如何num变量的地址是不会改变的。可是想一想我们打印的num地址是不是真正的地址呢？答案是否定的，这个地址是给我们程序员使用的虚拟内存地址，最后都会通过内核映射到实际的物理内存中去，所以，如果要出现我们程序运行的这种情况，只有一种可能，我们打印的是num的虚拟内存地址，它是无论如何不会改变的，可是num变量的值是独立的，那是因为通过num的地址映射的物理地址是不一样的，所以在物理内存中num应该是由两个的，只是他们两都映射到一个虚拟内存地址。 
总结 
上面并没有说的很清楚，并且带有个人猜想的成分，这里经过相关资料的查找，发现差不多是这样子的。

首先，子进程是完全复制父进程的，所以num的地址是一样的，可是子进程复制的是虚拟地址空间，而非物理空间。如果，子进程和父进程对变量只读，也就是说变量不会被改变，这时候，变量表现为共享的,此时物理空间只有一份。如果说父进程或者子进程需要改变变量，那么进程将会对物理内存进行复制，这个时候变量是独立的，也就是说，物理内存中存在两份空间。
————————————————
版权声明：本文为CSDN博主「浅浅的i」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/weixin_39578364/article/details/78995433