物理内存和虚拟内存的管理

ゝ一纸荒年。 2022-03-02 09:46 448阅读 0赞

# 1、介绍 #

内存是计算机中最重要的资源之一,通常情况下，物理内存无法容纳下所有的进程。虽然物理内存的增长现在达到了N个GB，但比物理内存增长还快的是程序，所以无论物理内存如何增长，都赶不上程序增长的速度，所以操作系统如何有效的管理内存便显得尤为重要。本文讲述操作系统对于内存的管理的过去和现在，以及一些页替换的算法的介绍。

# 2、虚拟内存与物理内存 #

**先说说为什么会有虚拟内存和物理内存的区别。**正在运行的一个进程，他所需的内存是有可能大于内存条容量之和的，比如你的内存条是256M，你的程序却要创建一个2G的数据区，那么不是所有数据都能一起加载到内存（物理内存）中，势必有一部分数据要放到其他介质中（比如硬盘），待进程需要访问那部分数据时，在通过调度进入物理内存。所以，虚拟内存是进程运行时所有内存空间的总和，并且可能有一部分不在物理内存中，而物理内存就是我们平时所了解的内存条。有的地方呢，也叫这个虚拟内存为内存交换区。关键的是不要把虚拟内存跟真实的插在主板上的内存条相挂钩，虚拟内存它是“虚拟的”不存在，假的啦，它只是内存管理的一种抽象！  
**        那么，什么是虚拟内存地址和物理内存地址呢。**假设你的计算机是32位，那么它的地址总线是32位的，也就是它可以寻址0~0xFFFFFFFF（4G）的地址空间，但如果你的计算机只有256M的物理内存0x~0x0FFFFFFF（256M），同时你的进程产生了一个不在这256M地址空间中的地址，那么计算机该如何处理呢？回答这个问题前，先说明计算机的内存分页机制。  
        **映射关系。**计算机会对虚拟内存地址空间（32位为4G）分页产生页（page），对物理内存地址空间（假设256M）分页产生页帧（page frame），这个页和页帧的大小是一样大的，所以呢，在这里，虚拟内存页的个数势必要大于物理内存页帧的个数。在计算机上有一个页表（page table），就是映射虚拟内存页到物理内存页的，更确切的说是页号到页帧号的映射，而且是一对一的映射。但是问题来了，虚拟内存页的个数 > 物理内存页帧的个数，岂不是有些虚拟内存页的地址永远没有对应的物理内存地址空间？不是的，操作系统是这样处理的。操作系统有个页面失效（page fault）功能。操作系统找到一个最少使用的页帧，让他失效，并把它写入磁盘，随后把需要访问的页放到页帧中，并修改页表中的映射，这样就保证所有的页都有被调度的可能了。这就是处理虚拟内存地址到物理内存的步骤。  
   **   ** **现在来回答什么是虚拟内存地址和物理内存地址**。虚拟内存地址由页号（与页表中的页号关联）和偏移量组成。页号就不必解释了，上面已经说了，页号对应的映射到一个页帧。那么，说说偏移量。偏移量就是我上面说的页（或者页帧）的大小，即这个页（或者页帧）到底能存多少数据。举个例子，有一个虚拟地址它的页号是4，偏移量是20，那么他的寻址过程是这样的：首先到页表中找到页号4对应的页帧号（比如为8），如果页不在内存中，则用失效机制调入页，否则把页帧号和偏移量传MMU（CPU的内存管理单元）组成一个物理上真正存在的地址，接着就是访问物理内存中的数据了。总结起来说，虚拟内存地址的大小是与地址总线位数相关，物理内存地址的大小跟物理内存条的容量相关。

# 3、内存分配 #

*  抽象，逻辑地址空间；
 *  保护，独立地址空间；
 *  共享，访问相同内存；
 *  虚拟化，更多的地址空间，对应用程序透明

**操作系统管理内存的不同机制：**

*       程序重定位，分段，分页，虚拟内存，按需分页虚拟内存

**OS本身也是软件，实现高度依赖于硬件，要知道内存架构，MMU（内存管理单元，硬件组件中负责处理CPU的内存访问请求）**

## 3.1、连续内存分配：内存碎片与分区的动态分配 ##

物理内存分配可以分为连续分配和非连续分配。  
        连续分配会造成内存碎片问题，空闲内存不能被利用。**外部碎片**，在分配单元时未使用内存，**内部碎片**，分配单元后的未使用内存。

**简单的内存管理方法：**

*  首次适配：从0地址往后查找和使用第一个可用空闲快（要比需要的空间大）。基本实现机制要求把空闲的内存块按地址排序。回收要考虑能否合并内存块。优点：简单，易于产生更大的空闲快，向着地址空间的结尾。劣势：易产生外部碎片（随着动态分配加剧），不确定性
 *  最优适配：找比需求大但最接近需求的空闲内存块，产生尽可能小的内存碎片。原理是为了避免分配大空闲块，最小化外部碎片，要求对空闲地址快按尺寸size排序，回收要合并。优点：当大部分分配需要小空间时使用，简单。缺点：外部碎片太小太细，不利于后续重分配。
 *  WORSTFIT 最差匹配：使用最大的空闲快，大块拆分变小块，可以避免产生太多微小的碎片，也要排序，回收合并。优势：分配中大型SIZE时实用。缺点：重分配慢，对大块的请求可能没得用了。

## 3.2、非连续内存分配：分段、分页 ##

### **内存的分段机制（用户所需）** ###

前面说得都是一次将整个程序放入到某一块空闲内存里面。但是事实上是这样吗？不是的，因为内存是分段，为什么内存会分段？因为程序是分段的。程序员眼中的程序：

![20190323120845388.png][]

在程序员眼中的程序是分为很多段的，每一段都有不同的特点。适用于不同的领域。每一段都是从该段的地址0开始的。就是说主程序存放的地方地址应该是从零开始的，变量存放的地方地址也应该是从零开始的，其他区域也是如此。用户程序里面每个区域都有其自己的特点，比如主程序这部分应该是只读的，变量所在的区域是可写的，函数库应该是可以可以链接也可以不链接的，栈应该只能单向增加。如果是将整个程序都放在一块的话这些要求肯定不能保证。因此程序应该是要分段保存的，并且这些段都有自己的特点。  
        既然是分段的，那么是怎么定义地址的呢？还是基址+偏移。只不过这里的基址不再是这个程序的起始位置了，而是这一段程序的起始地址。这个基址放在段表里面：

![20190323121007310.png][]

CPU每执行一条牵涉到地址的指令都会查一下PCB里面这个进程段表，从而确定物理地址。这个表其实就是LDT表，有一个专门存放该表地址的寄存器LDTR寄存器。到目前为止内存已经可以使用起来了。因为地址已经设定好了。

## **内存的分页机制（计算机所需）** ##

比如有一个160K的内存请求，但是空闲分区表里面只有一个150K的和一个50K的，都不够，怎么办。这其实就是内存碎片。一种方式是内存紧缩，即将150K的内存大小和50K的想办法移到一起。但是这种方式比较耗费时间，并且这段时间电脑是不能工作的。那有没有方法可以消除掉内存碎片呢？答案是将内存分页

将页作为内存分配的最小单元，假设一页为4K，如果一个内存请求是13K，那么就给它分配4页。这样一个进程最多也只会浪费不到4K的内存区域，这种浪费是很小的，因此也不需要进行内存紧缩了。那这种方式会产生内存碎片吗？其实也有会一些内存没有使用到，但是注意这种思想，页是一个单位，每次分配的内存都是整数个页，也就是将这些分配出去的页都看成是已经使用的了，所以就没有内存碎片。因此从内存角度来说这种方式是比较好的，也就是物理内存想要分页，但是用户程序希望是分段。

## 虚拟内存（分段+分页）、物理内存（分页） ##

段管理机制对于Intel处理器来说是最基本的, 任何时候都无法关闭. 也就是说, 即使启用页管理功能, 分段机制依然是起作用的, 段部件依然工作。根据应用程序大小找到段（注意段的大小是页的整数倍，这样才可以把段分成多个页）。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0ppblhZYW4_size_16_color_FFFFFF_t_70][]

如上图所示, 内存的分配设计段空间的分配和页分配. 左边是虚幻的, 或者说虚拟的4GB内存空间, 称为虚拟内存; 右边是实实在在的内存, 被分成1048576个4KB的页面(每个方框4KB, 灰色代表已分配).

在分页模式下, 操作系统可以创建一个为所有任务公用的4GB虚拟内存空间, 也可以为每一个任务创建独立的4GB虚拟内存空间, 这都是可行的. 当一个程序加载时, 操作系统既要在左边的虚拟内存中分配段空间, 又要在右边的物理内存中分配相应的页面. 因此, 第一步骤是寻找空闲的段空间, 该段空间既没有被其他程序使用, 也没有被同一程序内的其他段使用. 比如上图, 假设已经成功找到并分配了一个段空间, 基地址为0x00200000, 长度为8200字节.

页的最小尺寸是4KB, 也就是4096字节, 因此, 8200字节的段, 需要占用3个页面, 其中最后一个页面只用了8个字节, 其余都是浪费着, 但这无关紧要, 如果允许页共享, 多个段或多个程序可以用同一个页来存放各自的数据. 在分段之后, 操作系统的任务就是把段拆开, 并分别映射到物理页. 注意, **段必须是连续的, 但不要求所分配的页都是连续的**, 挨在一起的.

[详解参考][Link 1]

[20190323120845388.png]: /images/20220302/e34051c4bd2444fcbc95b05d576b4bb4.png
[20190323121007310.png]: /images/20220302/cacfcf1fc7de44aa8960e1e90842a71d.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0ppblhZYW4_size_16_color_FFFFFF_t_70]: /images/20220302/8b17fff3b2204a73a019065896f06e16.png
[Link 1]: https://blog.csdn.net/baixiaoshi/article/details/49851917