首先，使用最原始的標記分配方法，系統需要維護一個簡單的記憶體資訊表：

當程式申請一個長度為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個記憶體空間。

以上就是基本原理，實際系統中會做非常多的優化。目前各種主流作業系統都是分頁的方式，因此你不需要太關心碎片。

這個話題再延伸下去，就是一個程式內部的區域性記憶體池了。不過這是另一個問題，喜歡的話可以深究一下。