Linux虚拟地址空间

拼搏现实的明天。 2024-03-27 14:07 10阅读 0赞

#### 目录 ####

*   *  父子进程地址相同的变量值不同问题
     *   *  运行结果
     *  Linux下进程虚拟地址空间分布
     *  什么是虚拟地址空间？
     *  进程直接访问物理内存（无虚拟空间）
     *  再述虚拟地址空间！
     *  虚拟地址空间结构体是如何区域划分?
     *  解答最初的问题
     *  延伸问题: 一个pid变量怎么可能保存不同的值？
     *  为什么存在虚拟地址空间？（虚拟地址空间的好处）
     *   *  保护物理内存
         *  内存管理和进程管理低耦合
         *  延时分配，提高整机效率
         *  使内存分布有序化，实现进程独立性
         *  内存扩展(物理内存不够时，通过内存页和硬盘的交换达到扩展(了解)
         *  内存共享(允许多进程通过虚拟地址+页表等机制，访问同一个物理内存(eg:fork的写时拷贝)(了解)
     *  小结

### 父子进程地址相同的变量值不同问题 ###

#include<stdio.h>
    #include<unistd.h>
    int g_val = 100;
    
    
    int main()
    {
        
            pid_t id = fork();
            
        
    	if (id == 0)
    	{
        
    		// 子进程
    		int i = 0;
    		while (1)
    		{
        
    			printf("I am child process, id:%d, g_val:%d, &g_val:%p\n", getpid(), g_val, &g_val);
    			i++;
    			if (i == 5)
    			{
        
    				g_val = 200;
    				printf("Child process changed g_val success!!!\n");
    			}
    			sleep(1);
    		}
    	}
    	else {
        
    		while (1)
    		{
        
    			printf("I am parent process, id:%d, g_val:%d, &g_val:%p\n", getpid(), g_val, &g_val);
    			sleep(1);
    		}
    	}
    	return 0;
    }

#### 运行结果 ####

[yzl@VM-4-5-centos tmp]$ ./proc
    I am parent process, id:28298, g_val:100, &g_val:0x601054
    I am child process, id:28299, g_val:100, &g_val:0x601054
    I am parent process, id:28298, g_val:100, &g_val:0x601054
    I am child process, id:28299, g_val:100, &g_val:0x601054
    I am child process, id:28299, g_val:100, &g_val:0x601054
    I am parent process, id:28298, g_val:100, &g_val:0x601054
    I am parent process, id:28298, g_val:100, &g_val:0x601054
    I am child process, id:28299, g_val:100, &g_val:0x601054
    I am parent process, id:28298, g_val:100, &g_val:0x601054
    I am child process, id:28299, g_val:100, &g_val:0x601054
    Child process changed g_val success!!!
    I am parent process, id:28298, g_val:100, &g_val:0x601054
    I am child process, id:28299, g_val:200, &g_val:0x601054
    I am parent process, id:28298, g_val:100, &g_val:0x601054
    I am child process, id:28299, g_val:200, &g_val:0x601054

上述代码为，创建子进程，若干秒后，子进程改变全局变量值，发现子进程与父进程打印此全局变量值时，**值不同，且地址相同**。

同一个地址处的值在同一时刻不可能不同，于是引出了[虚拟地址][Link 1]空间的概念。即这里子进程与父进程打印的地址并非实际的物理地址，而是一种**虚拟地址**（线性地址）。

### Linux下进程虚拟地址空间分布 ###

虚拟地址空间使得每个进程看待内存时都有一个统一的视角，并且在他们看来，内存的分布是井然有序的。具体分布如下图

![img][]

1.  栈堆相向增长，堆向高地址增长，栈向低地址增长。这两个区域是动态变化的。
2.  虚拟地址空间分为两个空间：1. 内核空间，在32位下占1G 2. 用户空间，在32位下占3G即\[0, 3GB\] 用户空间 \[3GB, 4GB\] 内核空间
3.  static修饰局部变量，本质上是将此变量属性变为全局属性，存储在全局区。而语法的限制使得此static变量仅能在局部可见。
4.  上图虚拟内存分布仅适用于Linux操作系统，不适于Windows。
5.  一个有关堆区的知识：当C语言使用malloc函数时，申请10字节空间，实际在内存中会占用大于10字节的空间，多出的空间用于存储一些属性。这也是为什么free时传首地址即可，而不需要传空间大小。

### 什么是虚拟地址空间？ ###

1.  虚拟地址空间（进程地址空间）在操作系统内核中是一个数据结构，在Linux内核中，就是一个struct结构体
2.  在Linux下，进程地址空间是一个名为mm\_struct的结构体，主要存储各区域（堆，栈，全局数据区，只读代码区等）的范围，即start和end，用于划分各个区域。
3.  页表是和虚拟地址空间结构体配套的内核数据结构，页表的作用是：保存对应进程中每一个虚拟地址到物理内存中的物理地址的映射关系。即起一个映射配对的作用。 因为实际上数据，代码，变量等肯定最终要存储在物理内存中。
4.  页表起映射作用，就类似于C++中的map数据结构，key 是虚拟地址， value是对应的物理地址
5.  每一个进程都有一份地址空间结构体变量mm\_struct和页表实例化对象。在磁盘中的二进制可执行程序加载到内存中时，要创建对应的PCB结构体，同时，也会创建对应的地址空间结构体变量和页表。

### 进程直接访问物理内存（无虚拟空间） ###

在早期计算机操作系统内部，**进程直接访问物理内存。这样做有很多弊端**。在说弊端之前，有一个点需要明确：内存本身是可以随意读写的，物理内存是不存在只读的情况的。

比如，**最典型的野指针问题，一个进程的野指针很容易破坏其他进程，甚至影响操作系统内的安全数据**。其次，进程直接访问物理内存，使得**进程和物理内存耦合度很大，内存管理变得不方便**，从而内存碎片等问题也变得更难处理。

基于进程直接访问物理内存的弊端，**衍生出虚拟地址空间**。

### 再述虚拟地址空间！ ###

![img][img 1]

程PCB，虚拟地址空间，页表，物理内存的关系大致如上图所示。

1.  PCB中有一个struct mm\_struct\* mm指针数据成员指向这个进程对应的mm\_struct

![img][img 2]

1.  因为内存本身是随意读写的，所以，在**地址空间+页表的作用下**，**可以在某些虚拟地址与物理地址的映射关系中**，用某些数据（比如页表中存储）表明这个内存是只读的。以此来保护某些数据。这些都是地址空间+页表的作用，而非使用内存的权限控制。
2.  基于第二点，**地址空间+页表可以对某些内存进行权限管理**，比如常量代码区设为只读。同时，对于某些内存的非法访问，也可以及时禁止。从而保护物理内存。
3.  我们知道，**进程是具有独立性**的，那么，在地址空间+页表的作用下，**只要使得**各个**进程的虚拟地址**通过页表**映射的物理内存是不同**的，**则可以保证进程之间互不干扰**，即进程独立性。

### 虚拟地址空间结构体是如何区域划分? ###

通过定义栈区，堆区，常量代码区，全局数据区等区域的start，end。来对这些区域进行划分。

比如栈区，堆区是动态变化的。那么只需要增大或者减小end，即可对栈区堆区的空间大小进行控制。再比如只读代码区，在源文件编译之后，可执行程序内部已经有了虚拟地址。若此文件加载到内存中变为进程，则mm\_struct中的常量代码区的start和end即可通过这些编译生成的虚拟地址来确定start和end

Linux内核源码  
![img][img 3]

如图，为Linux内核源码中mm\_struct的定义，即虚拟地址空间的定义。可以看到，它确实是通过定义各个区域的start，end来划分各个区域的。类型是unsigned long

### 解答最初的问题 ###

1 #include<stdio.h>
      2 #include<unistd.h>
      3 int g_val = 100;
      4 
      5 int main()
      6 {
        
      7     pid_t id = fork();
      8     if(id == 0)
      9     {
        
     10         // 子进程
     11         int i = 0;
     12         while(1)
     13         {
        
     14             printf("I am child process, id:%d, g_val:%d, &g_val:%p\n", getpid(), g_val, &g_val);
     15             i++;
     16             if(i == 5)
     17             {
        
     18                 g_val = 200;
     19                 printf("Child process changed g_val success!!!\n");
     20             }
     21             sleep(1);                                                                                                                                                                                        
     22         }
     23     }
     24     else {
        
     25         while(1)
     26         {
        
     27             printf("I am parent process, id:%d, g_val:%d, &g_val:%p\n", getpid(), g_val, &g_val);
     28             sleep(1);
     29         }
     30     }
     31     return 0;
     32 }

![img][img 4]

最初，父进程与子进程打印出同一个**变量地址相同，但是值不同**。我们现在知道了，**这个地址其实是虚拟地址**，而非物理地址。

**一个事实**：父进程创建子进程时，除了一些子进程独有的属性，比如典型的pid。其余大部分属性和数据都是从父进程那里拷贝过来的。包括mm\_struct 和 页表。

**所以**，起初，在子进程执行g\_val = 200;之前，也就是**修改这个全局变量之前**。因为子进程的mm\_struct和页表是直接从父进程那里拷贝过来的。故**父子进程的g\_val的虚拟地址，以及这个虚拟地址映射的物理内存中的数据都是一样的**。

这样做的原因是：如果有某些数据，父子进程都是只读的，也就是不会修改，那么这份数据在内存中只保存一份即可，没必要给子进程在内存中再创建一份相同的，只读的数据。(**写时拷贝**)

而当子进程执行g\_val = 200;时，这是子进程对这个全局数据执行写操作。因为父子进程访问的g\_val不应该互相干扰。故此时，OS在内存中的其他区域，拷贝了一个新的，子进程的g\_val，赋值为200，**并改变子进程的页表的映射关系即可！**（不需要改变g\_val的虚拟地址）。

从而当子进程修改g\_val后，**父子进程打印的这个全局数据的虚拟地址相同**，**但是映射到物理内存不同区域**，**值不相同**。才有了最初的现象。

这种子进程写数据时进行拷贝的操作，称为写时拷贝！

### 延伸问题: 一个pid变量怎么可能保存不同的值？ ###

pid_t pid = fork();

我们知道，**fork函数内部的主体逻辑就是创建子进程**，而当**fork函数return之前，则子进程已经创建好了**。

所以**有了两个进程执行流**，两个执行流**会执行两次return**。**其次**，return了两次给pid赋值，也就是**子进程执行流的return给pid本质就是对pid变量进行写操作**！会发生**写时拷贝**，那么各自就有各自的pid了（虽然虚拟地址相同，页表映射到物理内存是不同的，看到的是自己的pid变量）

> fork return两次，第二次return发生了写时拷贝，则父子进程各自在物理内存中，都有属于自己的id变量空间！
> 
> 只不过在用户层用同一个变量pid（虚拟地址）来标识了。

### 为什么存在虚拟地址空间？（虚拟地址空间的好处） ###

#### 保护物理内存 ####

*  凡是非法的访问或者映射，OS都会识别到，并终止你的进程。（页表机制会将虚拟地址空间会划分为多个页，通过设置页表项的权限位答到保护物理敏感内存的目的）

原因就是：比如const char\* p = “abcd”; p指针保存的是虚拟地址，且这个虚拟地址所映射的物理内存不可被写,这都是基于**虚拟地址空间(代码段不能修改等等)+页表**的作用。

除了这种保护只读的数据，当存在野指针或者非法访问时，虚拟地址空间+页表也能以某种方式告诉OS，从而OS可以发信号终止这个进程。

样一来，物理内存的访问都在OS的监管之下。**保护了物理内存，物理内存中的数据，其他进程，以及内核的相关有效数据**。

#### 内存管理和进程管理低耦合 ####

因为有虚拟**虚拟地址空间+页表**，**物理内存中的数据可以随意存储**。只要**保证虚拟地址可以通过映射找到对应的数据即可**

**物理内存管理** 和 **进程管理**因此可以做到**关联性很低**

内存管理模块和进程管理模块 **完成了解耦合**。在**操作系统层面，这两个模块关联性很低，维护成本也会降低**(各维护各的);

#### 延时分配，提高整机效率 ####

*  我们在C语言中进行malloc时，申请内存本质是**在虚拟地址空间中申**请，**并不会立即向物理申请内存空间**。

原因是：**如果我malloc时就立刻申请物理内存，且不立刻使用**，则这就是一种**内存资源浪费**。

所以，因为有地址空间存在，上层申请内存，其实是在虚拟地址空间中申请。

**而当你进行对物理内存的访问时，才执行相关的内存管理算法（缺页中断等），帮你申请内存，构建页表映射关系**。然后再让你进行内存访问。 （这些是由操作系统完成的，进程0感知）

> 虚拟地址存在，但是物理内存中没有对应的空间。称为缺页（映射）中断。

那么，这样**延时分配的好处**就是：确保**物理内存中的有效使用是100%的**，**不会出现物理内存中申请空间但不使用的情况**。提高整机效率。

#### 使内存分布有序化，实现进程独立性 ####

*  地址空间+页表的存在，可以使得内存分布有序化！每个进程看到的是完整的虚拟地址->实现进程独立;

**在虚拟地址中**，每个进程以完整虚拟地址的角度来看待内存布局，这个布局是有序的（代码段，数据段，堆栈等分区）;

> 因为页表的存在，可以建立虚拟地址和物理地址的映射关系，物理内存存放的数据是随机无序的。

通过让不同进程看到的完整分布的**内存虚拟地址 映射 到物理内存**的任意区域 -> 实现进程独立性

#### 内存扩展(物理内存不够时，通过内存页和硬盘的交换达到扩展(了解) ####

#### 内存共享(允许多进程通过虚拟地址+页表等机制，访问同一个物理内存(eg:fork的写时拷贝)(了解) ####

### 小结 ###

综上:

可以说虚拟地址空间**是OS内核中的一种数据结构**，**主要保存各个数据区的start和end**。

32位系统下，**虚拟地址空间使得每个进程都认为自己独占4GB内存**，它们也看不到其他进程的存在。内核通过页面的映射等管理手段，从而让物理内存中的进程和进程之间，进程和内核之间可以互不干扰;

[Link 1]: https://so.csdn.net/so/search?q=%E8%99%9A%E6%8B%9F%E5%9C%B0%E5%9D%80&spm=1001.2101.3001.7020
[img]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/27/91bc604529c844ad9fb54b9aeea6e6d3.png
[img 1]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/27/cc1e3659608d4968a93e1ab397abd675.png
[img 2]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/27/a142d3145c264f2c812be80e524bfefc.png
[img 3]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/27/0001eb6f837f4df78b706dafe18b3d65.png
[img 4]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/27/200c728bb1324f21ada96b64ca203e80.png