記憶體池技術

記憶體池技術是一種飽受爭議的技術

爭議熱點在於到底有沒有必要自己實現。

1.記憶體池技術出現在libc尚不成熟的時候，當時程式經常在執行一段時間後效能下降，當時維護記憶體池很有必要

2.現在64位伺服器經常是32g以上的記憶體，管理記憶體碎片意義不打

3.寫malloc的各位都是大神，自己寫有99%的可能會更差，更何況現在還有tmalloc、jmalloc等與時俱進的記憶體管理庫。

4.記憶體資料庫等以記憶體為主的伺服器程式可以自己管理記憶體來達到某些特殊的公平，比如效能才是我們認為的供公平，浪費記憶體是可以接受的，諸如此類有特殊公平需求的。

記憶體池的實現方案

1.freelist

stl的二級記憶體配置器就是freelist

2.slab

memcached的記憶體管理方案

freelist實現方案

一句話描述：用鍊錶把待釋放的記憶體儲存起來重複利用。

stl的二級配置器實現的部分內容：

儲存已釋放記憶體的資料，每乙個項都包含乙個指向固定大小的區塊的單鏈表指標，指標指向可重複利用記憶體list，區塊的大小是隨著下標遞增的：8、16、24、32、40、48、56、64、72、80、88、96、104、112、120、128。

memory pool

記憶體池，當free_list找不到可重複利用的記憶體時就向memory pool申請，通過記憶體池申請記憶體時會申請20*size的記憶體，返回第一塊size記憶體給客戶，其他的19個size記憶體新增到free_list對應下標的可**利用區塊鍊錶。

memory pool的記憶體**

維護start和end兩個指標表示當前的水位，水位充足時直接分配記憶體給客戶。

水位不足時malloc2*20*size+fixed_size的長度，20*size用於返回客戶和加入free_list，其他的留在記憶體池中。

stl的二級記憶體配置器目的

**利用小於等於128位元組的小記憶體，避免記憶體碎片。

slab實現方案

memcached的實現方案

slabclass是乙個全域性陣列

slabclass中的slab的size按照配置的factor因子遞增

slabclass的slab_list包含的slab大小都是一樣的

**的slab加入slots

申請新的slat的時候優先利用slots中的可**記憶體。

以上slab的設計可以在原始碼slabs.c中檢視詳細，從slabs_init開始是乙個不錯的主意。

item和這裡的關係並不大，是申請記憶體的客戶用的。