内存碎片产生原因

原文地址：https://blog.csdn.net/csdn_kou/article/details/82891141（这里备注下：可能上面还有一个原文链接，是csdn转载的文章类型自动加上去的，这里保持习惯吧。）

以下是正文：

内存碎片通常分为内部碎片和外部碎片：

1. 内部碎片是由于采用固定大小的内存分区，当一个进程不能完全使用分给它的固定内存区域时就产生了内部碎片，通常内部碎片难以完全避免；
2. 外部碎片是由于某些未分配的连续内存区域太小，以至于不能满足任意进程的内存分配请求，从而不能被进程利用的内存区域。

  现在普遍采用的段页式内存分配方式就是将进程的内存区域分为不同的段，然后将每一段由多个固定大小的页组成。通过页表机制，使段内的页可以不必连续处于同一内存区域，从而减少了外部碎片，然而同一页内仍然可能存在少量的内部碎片，只是一页的内存空间本就较小，从而使可能存在的内部碎片也较少。

解决办法：

首先，使用最原始的标记分配方法，系统需要维护一个简单的内存信息表：

当程序申请一个长度为3的内存空间后：

当程序再申请一个长度为2，以及长度为4的内存空间后：

此时，只剩1个可用空间。如果这时程序再来申请长度大于1的空间，就申请不了，也就是内存不够。

现在，释放掉ID=2的空间：

我们发现，现在可用内存空间为3，但是，这3个空闲空间，并不是连续的。所以，如果程序现在申请长度为3的内存空间，同样会申请不了，会出现内存不够。业界把这种情况，称之为【内存碎片】。

明明剩余有3个空间，却申请不了3个内存空间，这TMD扯蛋？

于是，工程师们，发明了基于页面的内存管理方式：

首先，把物理内存，按照某种尺寸，进行平均分割。比如我现在以2个内存单位，来分割内存，也就是每两个连续的内存空间，组成一个内存页：

接着，系统同样需要维护一个内存信息表：

现在，程序申请长度为3的内存空间，不过由于现在申请的最小单位为页面，而一个页面的长度为2，因此现在需要申请2个页面，也就是4个内存空间。你看，这就浪费了1个内存空间。

接着，程序再申请长度为1，长度为2的空间：

释放掉ID=2，内存页ID为3的那条内存空间信息：

现在，就出现了之前的情况：目前一共有4个内存空间，但是不连续。不过，因为现在是分页管理机制，因此，现在仍然可以继续申请长度为4的内存空间：

 

这种方案是不是爽得多？没有碎片，能够尽量地全部用完空间。但仔细想想，这种优势背后，也是需要付出大量代价的。

前面那种内存分配方式，虽然容易出现碎片，并且内存空间的利用率低，但是使用性能高，程序能直接从内存信息表获取内存地址，接着就可以直接按照地址来使用内存空间了。

但下面这种分页的方式，程序需要记录的是内存页ID，每次使用时，需要从内存页ID翻译成实际内存地址，多了一次转换。而且这种模式，会浪费一些内存，比如上面申请3个内存空间，实际分配了2个页面共4个内存空间，浪费了1个内存空间。

以上就是基本原理，实际系统中会做非常多的优化。目前各种主流操作系统都是分页的方式，因此你不需要太关心碎片。

这个话题再延伸下去，就是一个程序内部的局部内存池了。不过这是另一个问题，喜欢的话可以深究一下。