感覺面試的時候經常會被問到這個問題，然后我也學習了一下Memcached的slab機制，發現很多服務器都是使用這種機制來分配內存，所以決定學習一下。
首先，先對內存分配中的伙伴系統有初步的了解：
在編程和使用的服務器軟件中，經常需要分配一組連續的頁框，而頻繁地申請和釋放不同大小的連續頁框，必然導致在已分配頁框的內存塊中分散了許多小塊的空閑頁框。這樣，即使這些頁框是空閑的，但要分配一個大塊的連續頁框就可能無法滿足?！ 《鴏inux采用了伙伴系統來解決上述難題。把所有的空閑頁框分組為11個塊鏈表，每個塊鏈表分別包含大小為1，2，4，8，16，32，64，128，256，512和1024個連續頁框的頁框塊。最大可以申請1024個連續頁框，對應4MB大小的連續內存。每個頁框塊的第一個頁框的物理地址是該塊大小的整數倍。例如，大小為16個頁框的塊，其起始地址是16×212的倍數。假設要申請一個256個頁框的塊，先從256個頁框的鏈表中查找空閑塊，如果沒有，就去512個頁框的鏈表中找，找到了則將頁框塊分為2個256個頁框的塊，一個分配給應用，另外一個移到256個頁框的鏈表中。如果512個頁框的鏈表中仍沒有空閑塊，繼續向1024個頁框的鏈表查找，如果仍然沒有，則返回錯誤。頁框塊在釋放時，內核會主動將兩個互為伙伴的頁框塊合并為一個較大的頁框塊，成功后會試圖尋找伙伴并合并為更大的內存塊，直至塊的大小超過上限或者沒有伙伴為止?；榛锇榈膬蓚€內存塊必須符合以下條件： 1、兩個塊具有相同的大小； 2、兩個塊的物理地址連續； 3、第一個快的物理地址是兩個塊大小的整數倍。 slab分配機制則是對伙伴算法的改進，slab（Slab Allocation）的設計理念是基于對象緩沖的，基本想法是避免重復大量的初始化和清理操作。slab主要可以用于頻繁非配釋放的內存對象。替代malloc/free 改進的地方在于：它對內存區的處理并不需要進行初始化或回收。出于效率的考慮，Linux并不調用對象的構造或析構函數，而是把指向這兩個函數的指針都置為空。Linux中引入Slab的主要目的是為了減少對伙伴算法的調用次數。
實際上，內核經常反復使用某一內存區。例如，只要內核創建一個新的進程，就要為該進程相關的數據結構（task_struct、打開文件對象等）分配內存區。當進程結束時，收回這些內存區。因為進程的創建和撤銷非常頻繁，因此，Linux的早期版本把大量的時間花費在反復分配或回收這些內存區上。從Linux2.2開始，把那些頻繁使用的頁面保存在高速緩存中并重新使用?？梢愿鶕却鎱^的使用頻率來對它分類。對于預期頻繁使用的內存區，可以創建一組特定大小的專用緩沖區進行處理，以避免內碎片的產生。對于較少使用的內存區，可以創建一組通用緩沖區（如Linux2.0中所使用的2的冪次方）來處理，即使這種處理模式產生碎片，也對整個系統的性能影響不大。
硬件高速緩存的使用，又為盡量減少對伙伴算法的調用提供了另一個理由，因為對伙伴算法的每次調用都會“弄臟”硬件高速緩存，因此，這就增加了對內存的平均訪問次數。
Slab分配模式把對象分組放進緩沖區
對于小對象， 就把Slab的描述結構slab_t放在該Slab中；對于大對象，則把Slab結構游離出來，集中存放。關于Slab中的著色區再給予具體描述： 每個Slab的首部都有一個小小的區域是不用的，稱為“著色區（coloring area）”。著色區的大小使Slab中的每個對象的起始地址都按高速緩存中的”緩存行（cache line）”大小進行對齊（80386的一級高速緩存行大小為16字節，Pentium為32字節）。因為Slab是由1個頁面或多個頁面（最多為32）組成，因此，每個Slab都是從一個頁面邊界開始的，它自然按高速緩存的緩沖行對齊。但是，Slab中的對象大小不確定，設置著色區的目的就是將Slab中第一個對象的起始地址往后推到與緩沖行對齊的位置。因為一個緩沖區中有多個Slab，因此，應該把每個緩沖區中的各個Slab著色區的大小盡量安排成不同的大小，這樣可以使得在不同的Slab中，處于同一相對位置的對象，讓它們在高速緩存中的起始地址相互錯開，這樣就可以改善高速緩存的存取效率。 每個Slab上最后一個對象以后也有個小小的廢料區是不用的，這是對著色區大小的補償，其大小取決于著色區的大小，以及Slab與其每個對象的相對大小。但該區域與著色區的總和對于同一種對象的各個Slab是個常數。 每個對象的大小基本上是所需數據結構的大小。只有當數據結構的大小不與高速緩存中的緩沖行對齊時，才增加若干字節使其對齊。所以，一個Slab上的所有對象的起始地址都必然是按高速緩存中的緩沖行對齊的。參考：深入分析Linux內核源碼http://oss.org.cn/kernel-book/ Memcached 源碼分析新聞熱點
疑難解答
