操作系统_内存管理

内存管理

虚拟内存

没有操作系统的单片机程序是直接使用物理地址的，但对于有操作系统的电脑而言，直接操作物理地址简直不能忍，现在的应用程序这么多，直接操作物理地址会产生一系列严重的问题，例如我存在某个位置的数据会被其他应用程序擦除。

因此我们需要有一个虚拟内存地址，应用程序可以在自己的虚拟地址内随意玩耍，操作系统负责将你的虚拟内存映射成物理内存。这个管理者在操作系统中被称为 MMU （Memery Management Unit）内存管理单元。

于是我们就可以进行快乐的面向虚拟地址编程啦~

内存分段

内存分段的内存管理机制是比较容易想到，也是最先出现的。既然我们不希望一次加载这个程序的全部数据、代码等，那么就将其按逻辑划分成代码段、数据段等，MMU 在操作的时候是一段一段的。

那么分段机制是如何找到物理地址呢？

通过段表进行映射。分段机制下的虚拟地址由两部分组成，段选择子与段内偏移量，通过这两部分的数据，计算机就可以计算出物理地址。

分段管理机制很好理解，但问题很严重，例如很容易产生内存碎片、内存交换的效率低。

产生内存碎片的原因在于，操作系统每次分配内存都是按段来分配的，那么在释放内存的时候肯定也是按段来释放的，那么这就容易发生的问题。

假如我连续分配了好几段内存，接着再释放中间某个 128M 的内存空间，那么中间这 128M 就比较难使用，如果下一个要分配的空间大于 128M，那么这个地方就无法使用，于是就产生了内存碎片。

除此之外，由于段的粒度比较大，内存交换的效率也比较低。集中体现在内存与硬盘速度不一致上，根据局部性原理，操作系统在加载程序的时候，肯定不是一次性加载全部数据的，而是加载必要部分，其他部分在需要的时候再从硬盘上换出来，同时操作系统将部分暂时用不到的数据换出。而因为段的粒度较大，于是就产生了交换效率较低这个问题。

内存分页

为了解决内存分段所带来的这两个问题，内存分页的虚拟内存机制诞生了。

我们前面说过内存分段产生问题的原因是段的粒度较大，既然如此，我们降低粒度就好了，内存分页。

在正式讲内存分页之前，先来科普一下内存分页相关的前置知识（Linux 系统下）

• 一张页表 4KB
• 每张页表含 1024 个页表项
• 每个页表项占 4B
• 每个页表项均指向一张页表

有了这些知识，我们就可以开始下面的学习了。

操作系统的一页很小，才 4KB，那么需要多少页才能映射 32位操作系统 4GB 内存呢？

根据前置知识，我们需要 4GB / 4KB 页，大约 100万页。

那么映射这 100万页，我们需要多少张页表呢，100万 / 1024 = 1024 张页表。

那么 1024 张页表占用多少内存空间？ 1024 * 4 KB = 4MB。

根据前面的计算，我们已经得到答案了，为了映射这 4GB 的内存，我们需要 4MB 的内存空间来进行映射。

每开始一个新的进程，我们都需要将其虚拟地址映射成物理地址，所以每一个进程，我们都需要给它配 4MB 的页表。

这显然是资源浪费的，我们需要一个更加节约的解决方案。

问题就是这样，提出了新的解决方案，必定会带来新的问题。

计算机科学家们，提出了多级页表的解决方案。

既然 4GB 内存 需要 1024 张页表进行映射，那么我搞两级页表行不行？

既一级页表只有一张页表共 1024 个页表项，这 1024 个页表项对应 1024 张二级页表。

也就是说，我们一共会 占用 4KB + 4MB 的内存空间。

事实真的是如此吗？

如果只是如此，那也太小瞧我们计算机科学家了，事实上，这个解决方案的思路很清晰，首先一级页表是常驻内存中的，也就说 4KB 必须要占用，但二级页表却不需要，因为程序的运行是有热点代码的，可能这个程序有 1GB 那么大，但一直在使用的可能只有 200MB，于是我们的二级页表也不需要全部开启，哪个位置开启就使用哪部分二级页表即可。

于是内存占用就变成了，4KB + 4MB * 0.2 。

很神奇吧。

段页式

掌握了前面的内存分段以及内存分页的解决方案后，段页式其实就很好理解了。

本质上就是在内存分段的基础上，再进行内存分页。

好处就是粒度有小有大，内存空间的占用偏小。

不好的地方在于映射的次数过多，影响效率。