簡(jiǎn)單的寫(xiě)寫(xiě),看完了memcached的這部分代碼之后覺(jué)得跟我的ccache還是很像的.
1) 分配
memcached中的內(nèi)存全部由類(lèi)型為slabclass_t的結(jié)構(gòu)體保存
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;
有一個(gè)全局的slabclass_t的數(shù)組,slabclass_t中的size字段保存每個(gè)slab所能保存的數(shù)據(jù)大小.在這個(gè)slabclass_t數(shù)組中,size字段都是遞增的,遞增的因子由slabs_init函數(shù)中的第二個(gè)參數(shù)factor參數(shù)指定.比如說(shuō),假如factor是2,那么如果第一個(gè)slabclass_t的size是unsigned int size = sizeof(item) + settings.chunk_size;(也是在slabs_init函數(shù)中的語(yǔ)句),那么下一個(gè)slabclass_t的size就是size*factor(這里忽略對(duì)齊的因素).
于是乎,假設(shè)第一個(gè)slab能保存8byte的數(shù)據(jù),factor為2,那么接下來(lái)的slab的size依次為16byte,32byte...
每次需要分配內(nèi)存,都需要根據(jù)所需分配的尺寸查找大于該尺寸的最小尺寸的slab,比如還是前面的那個(gè)slab模型,如果現(xiàn)在需要分配30byte的空間,查找得到大于30byte的最小slab尺寸是32byte,于是就從這個(gè)slab中查找item分配給它.
但是這里有一個(gè)問(wèn)題,就是多余資源的浪費(fèi),前面說(shuō)的30byte只是浪費(fèi)了2byte,但是如果現(xiàn)在要分配的是17byte,那么就浪費(fèi)了15byte,浪費(fèi)了將近50%!因此才有了前面需要指定factor的原因,使用者可以根據(jù)需要指定不同的增長(zhǎng)factor,以降低資源的浪費(fèi).
2) 淘汰
淘汰采用的是LRU算法,所有的最近使用的item保存在static item *tails[LARGEST_ID];(item.c)中,已經(jīng)分配的內(nèi)存會(huì)以鏈表的形式保存在這個(gè)數(shù)組中,如果對(duì)應(yīng)的slab已經(jīng)分配不到足夠的內(nèi)存,就到這個(gè)鏈表中查詢(xún),淘汰的依據(jù)是item結(jié)構(gòu)體中的exptime字段.
簡(jiǎn)單分析到此,需要更詳細(xì)的解釋就去看代碼吧,memcached中與這部分的代碼在slab.h(.c)/item.h(.c)中,兩個(gè)關(guān)鍵的結(jié)構(gòu)體是item和slabclass_t.