Linux: 进程地址空间究竟是什么？
一、内存究竟是什么？分为哪些？二、内存是真实物理空间？三、进程地址空间（虚拟地址）3.1 为何同一个变量地址相同，保存的数据却不同？
四、为什么需要地址地址空间和页表的存在？4.1 真实内存无序便有序4.2 进行内存安全检查4.3 进程管理和内存管理藕接
五、其他细节问题5.1 操作系统如何获取进程页表相关信息5.2 操作系统如何确定内存中是否分配空间、是否存在内容？
一、内存究竟是什么？分为哪些？
在C/C++中，我们常将内存分为：代码区、常量区、全局区（静态区）、堆、栈等等。相关内存区域划分如下：（X86, 32位平台) 如何验证C/C++中各区域的相对位置呢？
我们可以在每个区域中选择一个地址来验证C/C++中各区域的相对位置！！具体如下：
【源代码】：
#include
#include
#include
int un_global_val;
int Init_global_val = 100;
int main(int argc, char *argv[], char * env[])
{
printf("code addr: %p\n", main); //代码区
const char *str = "hello Linux";//字符常量区
printf("read only char add: %p\n", str);
printf("Init global value add: %p\n", &Init_global_val);//全局初始区
printf("uninit global value add: %p\n", &un_global_val);//全局未初始区
char* heap1 = (char*)malloc(100);
char* heap2 = (char*)malloc(100);
char* heap3 = (char*)malloc(100);
char* heap4 = (char*)malloc(100);
//堆及地址增长方向
printf("heap1 add: %p\n", heap1);
printf("heap2 add: %p\n", heap2);
printf("heap3 add: %p\n", heap3);
printf("heap4 add: %p\n", heap4);
//堆及地址增长方向
printf("stack1 add: %p\n", &heap1);
printf("stack2 add: %p\n", &heap2);
printf("stack3 add: %p\n", &heap3);
printf("stack4 add: %p\n", &heap4);
int i = 0;//命令行参数
for(; argv[i]; i++)
{
printf("argv[%d]: %p\n",i, argv[i]);
}
i = 0;//环境变量
for(; i < 2; i++)
{
printf("env[%d]: %p\n",i, env[i]);
}
return 0;
}
【运行结果】：
二、内存是真实物理空间？
在C/C++中，我们经常提及上述内存。但程序员口中的内存是真实物理空间吗？
下面我们在来看看这样一段代码：用fork创建一个子进程，并打印父进程和子进程对于的pid、ppid、全局变量值、全局变量地址。当子进程执行2次后，子进程修改全局变量。
【源代码】：
#include
#include
#include
int global_val = 100;
int main()
{
pid_t id = fork();
if(id == 0)
{
//child
int cnt = 3;
while(1)
{
printf("child Pid:%d Ppid:%d g_val:%d &g_val:%p\n", getpid(), getppid(), global_val, &global_val);
if(--cnt == 0)
{
global_val = 200;
printf("child change g_val 100 -> 200\n");
}
sleep(1);
}
}
else if(id > 0)
{
//pather
while(1)
{
printf("father Pid:%d Ppid:%d g_val:%d &g_val:%p\n", getpid(), getppid(), global_val, &global_val);
sleep(1);
}
}
return 0;
}
【运行结果】：
我们发现fork()创建的子进程对全局变量进行修改后，毋庸置疑父进程和子进程的值不同。但奇怪的是，父/子进程中，全局变量的地址竟然是一样的，未发生改变！！一块地址空间的值是唯一的。但上述现象中出现同一块变量却存在不同的值，说明父子进程中显示的地址不是真实的物理地址。在LInux中，我们将这种地址称之为虚拟地址。在C/C++中，我们看到的地址都是虚拟地址（进程地址空间）。真实地址都是由操作系统进行控制分配的，用户一概不知道！！
三、进程地址空间（虚拟地址）
3.1 为何同一个变量地址相同，保存的数据却不同？
原因在于在Linux中，操作系统会为每一个进程维护一个PCB、进程地址空间（也被称为虚拟地址空间）和页表。其中页表通过映射，将虚拟地址和真实物理地址进行藕接。操作系统可以通过页表，找到虚拟地址所对应的真实物理地址，进而找到相应的数据！！
当fork()创建子进程时，操作系统以父进程为模板将大部分属性拷贝给子进程，而页表就是其中之一。在数据未发生任何改变之前，父进程和子进程中页表的映射关系是相同的，指向同一块物理地址。但当父进程或子进程试图对数据进行修改时，为了保证父进程和子进程之间的独立性，操作系统会为该进程申请创建新的空间，然后将页表中的映射关系进行修改，指向新申请的物理空间。换而言之，数据不修改时指向同一块物理地址；数据修改后，各自私有一份！ 但在此过程中，操作系统仅仅是将页表中的映射关系进行修改。我们所看到的地址(虚拟地址)和变量并未发生改变。这也就意味着当父进程和子进程运行时，父进程和子进程的PCB、进程地址空间、和页表都是相互独立的，各自私有一份。尽管虚拟地址相同，但页表中的映射关系已经发生改变，此时我们获取虚拟地址对应的数据时，操作系统通过页表映射到不同的物理地址，从而获取到不同的值！（Linux中，进程PCB中存在一个struct mm_struct的结构体指向虚拟地址空间）
【具体如下】：（以栈上定义的变量gal为例）
创建子进程时，未发生数据修改。此时操作系统会以父进程为模板将大部分数据拷贝给子进程，并且共用代码。其中父进程页表中的数据直接拷贝给子进程页表。此时子进程中的虚拟地址通过页表的映射关系，和父进程指向同一块物理空间！
当子进程中的数据发生修改时，为了保证父进程和子进程的独立性，操作系统会为子进程的真实物理空间重新开辟一块空间，用于存储修改后的值。之后将子进程的页表中的映射关系进行调整，指向新空间。
四、为什么需要地址地址空间和页表的存在？
为什么不直接指向真实物理地址，而是通过进程地址空间和页表来间接寻址呢？其真实原因主要有以下几点：
4.1 真实内存无序便有序
在真实物理空间中，数据从磁盘加载到物理空间。但数据加载到什么位置呢？
其实数据可以加载到物理空间的任意位置。由于进程地址空间和页表的存在，进程不需要关系这个问题。操作系统会将该进程的数据通过页表映射起来，让进程以统一的方式看待内存。通过地址空间和页表将乱序的内存数据变为有序，分门别类的规划好！！同时当进程中的数据出现阻塞挂起等情况是，操作系统仅需修改页表中的映射相关属性即可，大大减少操作系统的内存和进程的管理成本！！！
4.2 进行内存安全检查
在页表中，还存在访问权限的字段。具体如下： 在该字段中，保存着当前数据时仅度、可读可写等权限。如果页表保存也数据的访问权限时r（比如代码区的数据），当用户对该数据试图进行修改时，页表中的访问权限会拦截禁止该行为。从而实现对进程访问内存的安全检查！！
【示例】： 下面有这样一段代码：
#include
int main()
{
char* str = "hello Linux\n";
*str = "fef";
return 0;
}
这段代码显然是无法成功运行的。原因在于char* str = "hello Linux\n"中，str是字符常量，操作系统将页表中str的相应访问权限字段设置为只读。当用户*str = "fef";试图对str中的数据进行修改时，操作系统识别到该数据不可被修改，直接被操作系统拦截。
4.3 进程管理和内存管理藕接
在进程被调度过程中，为代码和数据开辟内存、加载数据到内存，修改建立页表和物理地址的映射关系等等操作属于内存管理的范畴；而进程执行代码、进程被调度属于进程管理的范畴。 在整个过程中，内存管理不知道进程管理究竟在做什么、而进程管理同样不关心底层数据加载、内存分配的问题。由于进程地址空间和页表的存在，操作系统会将各自的需求传递给对方。从而实现进程管理和内存管理之间的接藕！！
五、其他细节问题
5.1 操作系统如何获取进程页表相关信息
在Linux中，进程的PCB保存了一个struct mm_struct结构体指针指向进程虚拟空间。但页表呢？ 其实当CPU调度进程时，CPU上存在一个名为CR3寄存器。该寄存器保存了当前调度进程页表的地址。当进程调度结束时，操作系统会将CR3寄存器中的内存保存到进程PCB的上下文中。
5.2 操作系统如何确定内存中是否分配空间、是否存在内容？
在系统中，存在这样几种情况。
各位在打游戏时，有些游戏非常大，多则上百G（比如原神）。但在32为平台下，内存只有4GB。内存显然不足，当我们发现游戏还是可以正常运行的。原因在于操作系统并不是一次性将所有数据全部加载到内存中，而是在进程执行过程中，临时将所需要的数据加载到内存。当操作系统中进程处于阻塞状态时，恰好此时操作系统内存资源严重不足。此时操作系统会将阻塞进程转化为挂起状态。将阻塞进程的相关数据置换到磁盘的Swap分区。当该进程被调度时，在重新加载到内存。这一点毛病没有。但问题在于操作系统如何知道内存中是否为这些数据分配空间、分配的空间中是否有内容呢？
原因在于：在进程页表中，存在一个字段（用0、1的方式）用于判断操作系统是否为该代码或数据分配内存空间、分配的空间中是否存在内容。（比如10表示以分配空间但没有内容，操作系统在识别到该信息后会先将相关数据加载到指定区域，在向后执行！！）
好文链接
您阅读本篇文章共花了：
发表评论