簡單的寫寫,看完了memcached的這部分程式碼之後覺得跟我的ccache還是很像的.

1) 分配
memcached中的記憶體全部由型別為slabclass_t的結構體儲存
typedef struct {
    unsigned int size;      /* sizes of items */
    unsigned int perslab;   /* how many items per slab */void**slots;           /* list of item ptrs */
    unsigned int sl_total;  /* size of previous array */
    unsigned int sl_curr;   /* first free slot */void*end_page_ptr;         /* pointer to next free item at end of page, or 0 */
    unsigned int end_page_free; /* number of items remaining at end of last alloced page */

    unsigned int slabs;     /* how many slabs were allocated for this class */void**slab_list;       /* array of slab pointers */
    unsigned int list_size; /* size of prev array */

    unsigned int killing;  /* index+1 of dying slab, or zero if none */
} slabclass_t;
有一個全域性的slabclass_t的陣列,slabclass_t中的size欄位儲存每個slab所能儲存的資料大小.在這個slabclass_t陣列中,size欄位都是遞增的,遞增的因子由slabs_init函式中的第二個引數factor引數指定.比如說,假如factor是2,那麼如果第一個slabclass_t的size是unsigned int size = sizeof(item) + settings.chunk_size;(也是在slabs_init函式中的語句),那麼下一個slabclass_t的size就是size*factor(這裡忽略對齊的因素).
於是乎,假設第一個slab能儲存8byte的資料,factor為2,那麼接下來的slab的size依次為16byte,32byte...
每次需要分配記憶體,都需要根據所需分配的尺寸查詢大於該尺寸的最小尺寸的slab,比如還是前面的那個slab模型,如果現在需要分配30byte的空間,查詢得到大於30byte的最小slab尺寸是32byte,於是就從這個slab中查詢item分配給它.
但是這裡有一個問題,就是多餘資源的浪費,前面說的30byte只是浪費了2byte,但是如果現在要分配的是17byte,那麼就浪費了15byte,浪費了將近50%!因此才有了前面需要指定factor的原因,使用者可以根據需要指定不同的增長factor,以降低資源的浪費.

2) 淘汰
淘汰採用的是LRU演算法,所有的最近使用的item儲存在static item *tails[LARGEST_ID];(item.c)中,已經分配的記憶體會以連結串列的形式儲存在這個陣列中,如果對應的slab已經分配不到足夠的記憶體,就到這個連結串列中查詢,淘汰的依據是item結構體中的exptime欄位.

簡單分析到此,需要更詳細的解釋就去看程式碼吧,memcached中與這部分的程式碼在slab.h(.c)/item.h(.c)中,兩個關鍵的結構體是item和slabclass_t.