memcached源码分析-----item锁级别与item引用计数

   转载请注明出处：http://blog.csdn.net/luotuo44/article/details/42913549

 

 

锁级别：

 

        从前面的《扩展哈希表》知道：哈希表进行扩展时，有一个专门的线程负责将item数据从旧哈希表迁移到新哈希表(因此，也称这个线程为迁移线程)。此外，还有一些worker线程会时不时访问item(包括插入、删除和获取)。这些线程的对item所做的操作基本上都是互斥的，必须加锁控制。

        如果只使用一个锁，抢到锁能使用哈希表，抢不到则不能使用。那么memcached的效率将变得相当低。为此，memcached采用类似数据库的策略：使用不同级别的锁。memcached定义了两个级别的锁：段级别和全局级别。在平时(不进行哈希表扩展时)，使用段级别的锁。在扩展哈希表时，使用全局级别的锁。

        段级别是什么级别？将哈希表按照几个桶一段几个桶一段地平均分，一个段对应有多个桶，每一个段对应有一个锁。所以整个哈希表有多个段级别锁。由于段级别锁的数量在程序的一开始就已经确定了，不会再变的了。而随着哈希表的扩展，桶的数量是会增加的。所以随着哈希表的扩展，越来越多的桶对应一个段，也就是说越来越多的桶对应一个锁。

 

        在哈希表扩展阶段，迁移线程和workers线程都使用全局锁。这些线程竞争全局锁，抢到锁才允许对哈希表的item进行操作。在非扩展阶段，迁移线程处于休眠状态，workers线程使用段级别锁，抢到了某个段锁就允许访问对应的多个桶。因此如果不同的worker线程访问不同的段，那么就可以同时访问了，增加了并发量。

      

        下面看一下段级别锁和全局级别锁的定义。thread_init函数分配并初始化段级别锁。

[cpp] view plain copy
 
 在CODE上查看代码片派生到我的代码片
  1. static pthread_mutex_t *item_locks;//指向段锁数组的指针  
  2. /* size of the item lock hash table */  
  3. static uint32_t item_lock_count;//段锁的数量  
  4. static unsigned int item_lock_hashpower;  
  5. static pthread_mutex_t item_global_lock;//全局锁  
  6.   
  7. #define hashsize(n) ((unsigned long int)1<<(n))  
  8.   
  9. void thread_init(int nthreads, struct event_base *main_base) {  
  10.     int         i;  
  11.     int         power;  
  12.   
  13.     pthread_mutex_init(&cache_lock, NULL);  
  14.   
  15.     pthread_mutex_init(&init_lock, NULL);  
  16.     pthread_cond_init(&init_cond, NULL);  
  17.   
  18.     //nthreads是workers线程的数量，由main函数调用时传入来  
  19.     if (nthreads < 3) {  
  20.         power = 10;  
  21.     } else if (nthreads < 4) {  
  22.         power = 11;  
  23.     } else if (nthreads < 5) {  
  24.         power = 12;  
  25.     } else {//最大为13  
  26.         /* 8192 buckets, and central locks don't scale much past 5 threads */  
  27.         power = 13;  
  28.     }  
  29.   
  30.     //power是2的幂  
  31.     item_lock_count = hashsize(power);  
  32.     item_lock_hashpower = power;  
  33.   
  34.     //哈希表中段级别的锁。并不是一个桶就对应有一个锁。而是多个桶共用一个锁  
  35.     item_locks = calloc(item_lock_count, sizeof(pthread_mutex_t));  
  36.     if (! item_locks) {  
  37.         perror("Can't allocate item locks");  
  38.         exit(1);  
  39.     }  
  40.     for (i = 0; i < item_lock_count; i++) {  
  41.         pthread_mutex_init(&item_locks[i], NULL);  
  42.     }  
  43.   
  44.   
  45.     pthread_mutex_init(&item_global_lock, NULL);  
  46.   
  47.     ...  
  48. }  

 

切换锁级别：

        现在看一下怎么使用段级别锁和全局级别锁。迁移线程并不会使用段级别锁，在assoc.c的assoc_maintenance_thread函数中，迁移线程只会调用item_lock_global()函数锁上全局锁item_global_lock。这里主要是看workers线程是怎么使用段级别锁和全局级别锁的。

 

worker线程的锁级别：

        workers线程如果要访问哈希表的item，会先调用item_lock函数进行加锁。item_lock函数会根据需要自动选择使用段级别锁还是全局级别锁。下面是具体的代码。

[cpp] view plain copy
 
 在CODE上查看代码片派生到我的代码片
  1. //memcached.h文件  
  2. //item锁级别  
  3. enum item_lock_types {  
  4.     ITEM_LOCK_GRANULAR = 0, //段级别  
  5.     ITEM_LOCK_GLOBAL //全局级别  
  6. };  
  7.   
  8. //thread.c文件  
  9. static pthread_key_t item_lock_type_key;//线程私有数据的键值  
  10.   
  11. void item_lock(uint32_t hv) {  
  12.     //获取线程私有变量  
  13.     uint8_t *lock_type = pthread_getspecific(item_lock_type_key);  
  14.     //likely这个宏定义用于代码指令优化  
  15.     //likely(*lock_type == ITEM_LOCK_GRANULAR)用来告诉编译器  
  16.     //*lock_type等于ITEM_LOCK_GRANULAR的可能性很大  
  17.     if (likely(*lock_type == ITEM_LOCK_GRANULAR)) {//使用段级别锁的概率很大  
  18.         //对某些桶的item加锁  
  19.         mutex_lock(&item_locks[hv & hashmask(item_lock_hashpower)]);  
  20.     } else {  
  21.         //对所有item加锁  
  22.         mutex_lock(&item_global_lock);  
  23.     }  
  24. }  
  25.   
  26. void item_unlock(uint32_t hv) {  
  27.     uint8_t *lock_type = pthread_getspecific(item_lock_type_key);  
  28.     if (likely(*lock_type == ITEM_LOCK_GRANULAR)) {  
  29.         mutex_unlock(&item_locks[hv & hashmask(item_lock_hashpower)]);  
  30.     } else {  
  31.         mutex_unlock(&item_global_lock);  
  32.     }  
  33. }  

 

        可以看到memcached根据线程私有变量(对应的键值为item_lock_type_key)确定当前要使用哪个锁。只要为每一个worker线程都设置键值为item_lock_type_key的线程私有数据。要切换锁，直接修改线程的私有数据即可。接着看一下workers线程私有数据的初始化。

[cpp] view plain copy
 
 在CODE上查看代码片派生到我的代码片
  1. static LIBEVENT_THREAD *threads;  
  2.   
  3. void thread_init(int nthreads, struct event_base *main_base) {  
  4.     ...  
  5.     pthread_key_create(&item_lock_type_key, NULL);  
  6.   
  7.     for (i = 0; i < nthreads; i++) {  
  8.         //创建worker线程，线程函数为worker_libevent, 线程参数为&threads[i]  
  9.         create_worker(worker_libevent, &threads[i]);  
  10.     }  
  11.     ...  
  12. }  
  13.   
  14. static void *worker_libevent(void *arg) {//这个函数也是在初始化时调用的  
  15.     LIBEVENT_THREAD *me = arg;  
  16.   
  17.     me->item_lock_type = ITEM_LOCK_GRANULAR;//初试状态使用段级别锁  
  18.     //为workers线程设置线程私有数据  
  19.     //因为所有的workers线程都会调用这个函数，所以所有的workers线程都设置了相同键值的  
  20.     //线程私有数据  
  21.     pthread_setspecific(item_lock_type_key, &me->item_lock_type);  
  22.     ...  
  23. }  

 

实现切换：

        可以看到每个线程的线程私有数据是每个线程都独有的LIBEVENT_THREAD结构体的成员变量item_lock_type。只要根据需要把workers线程的item_lock_type变量修改就可以完成锁的切换。哈希表迁移线程会在assoc.c文件中的assoc_maintenance_thread函数调用switch_item_lock_type函数，让所有的workers线程都切换到段级别锁或者全局级别锁。现在来看一下具体是怎么实现的。

[cpp] view plain copy
 
 在CODE上查看代码片派生到我的代码片
  1. void switch_item_lock_type(enum item_lock_types type) {  
  2.     char buf[1];  
  3.     int i;  
  4.   
  5.     switch (type) {  
  6.         case ITEM_LOCK_GRANULAR:  
  7.             buf[0] = 'l';//用l表示ITEM_LOCK_GRANULAR 段级别锁  
  8.             break;  
  9.         case ITEM_LOCK_GLOBAL:  
  10.             buf[0] = 'g';//用g表示ITEM_LOCK_GLOBAL 全局级别锁  
  11.             break;  
  12.         default:  
  13.             fprintf(stderr, "Unknown lock type: %d\n", type);  
  14.             assert(1 == 0);  
  15.             break;  
  16.     }  
  17.   
  18.     pthread_mutex_lock(&init_lock);  
  19.     init_count = 0;  
  20.     for (i = 0; i < settings.num_threads; i++) {  
  21.         //通过向worker监听的管道写入一个字符通知worker线程  
  22.         if (write(threads[i].notify_send_fd, buf, 1) != 1) {  
  23.             perror("Failed writing to notify pipe");  
  24.             /* TODO: This is a fatal problem. Can it ever happen temporarily? */  
  25.         }  
  26.     }  
  27.   
  28.     //等待所有的workers线程都把锁切换到type指明的锁类型  
  29.     wait_for_thread_registration(settings.num_threads);  
  30.     pthread_mutex_unlock(&init_lock);  
  31. }  
  32.   
  33. static void wait_for_thread_registration(int nthreads) {  
  34.     while (init_count < nthreads) {  
  35.         pthread_cond_wait(&init_cond, &init_lock);  
  36.     }  
  37. }  

 

        因为所有的workers线程都在处于event_base循环中，可以直接往workers线程监听的管道中写入一个字节就能通知workers线程了。

        迁移线程为什么要这么迂回曲折地切换workers线程的锁类型呢？直接修改所有线程的LIBEVENT_THREAD结构的item_lock_type成员变量不就行了吗？

        这主要是因为迁移线程不知道worker线程此刻在干些什么。如果worker线程正在访问item，并抢占了段级别锁。此时你把worker线程的锁切换到全局锁，等worker线程解锁的时候就会解全局锁(参考前面的item_lock和item_unlock代码)，这样程序就崩溃了。所以不能迁移线程去切换，只能迁移线程通知worker线程，然后worker线程自己去切换。当然是要worker线程忙完了手头上的事情后，才会去修改切换的。所以迁移线程在通知完所有的worker线程后，会调用wait_for_thread_registration函数休眠等待所有的worker线程都切换到指定的锁类型后才醒来。

 

        现在来看一下workers线程是怎么切换的。因为前面迁移线程往workers线程监听的管道写入了一个字符，所以我们直接看workers线程设置的管道event监听函数thread_libevent_process。

[cpp] view plain copy
 
 在CODE上查看代码片派生到我的代码片
  1. static void thread_libevent_process(int fd, short which, void *arg) {  
  2.     LIBEVENT_THREAD *me = arg;  
  3.     char buf[1];  
  4.   
  5.     if (read(fd, buf, 1) != 1)  
  6.         if (settings.verbose > 0)  
  7.             fprintf(stderr, "Can't read from libevent pipe\n");  
  8.   
  9.     switch (buf[0]) {  
  10.     ...   
  11.     case 'l':  
  12.     me->item_lock_type = ITEM_LOCK_GRANULAR;//切换item到段级别  
  13.     //唤醒睡眠在init_cond条件变量上的迁移线程  
  14.     register_thread_initialized();  
  15.         break;  
  16.     case 'g':  
  17.     me->item_lock_type = ITEM_LOCK_GLOBAL;//切换item锁到全局级别  
  18.     register_thread_initialized();  
  19.         break;  
  20.     }  
  21. }  
  22.   
  23.   
  24. static void register_thread_initialized(void) {  
  25.     pthread_mutex_lock(&init_lock);  
  26.     init_count++;  
  27.     pthread_cond_signal(&init_cond);  
  28.     pthread_mutex_unlock(&init_lock);  
  29. }  



按需切换：

 

        现在已经看完了基础设施的构建，来看回迁移线程是怎么调控一切的吧。

[cpp] view plain copy
 
 在CODE上查看代码片派生到我的代码片
  1. void item_lock_global(void) {  
  2.     mutex_lock(&item_global_lock);  
  3. }  
  4.   
  5. void item_unlock_global(void) {  
  6.     mutex_unlock(&item_global_lock);  
  7. }  
  8.   
  9.   
  10. static void *assoc_maintenance_thread(void *arg) {  
  11.   
  12.     //do_run_maintenance_thread是全局变量，初始值为1，在stop_assoc_maintenance_thread  
  13.     //函数中会被赋值0，终止迁移线程  
  14.     while (do_run_maintenance_thread) {  
  15.         int ii = 0;  
  16.   
  17.         /* Lock the cache, and bulk move multiple buckets to the new 
  18.          * hash table. */  
  19.         item_lock_global();//锁上全局级别的锁，全部的item都在全局锁的控制之下  
  20.         //锁住哈希表里面的item。不然别的线程对哈希表进行增删操作时，会出现  
  21.         //数据不一致的情况.在item.c的do_item_link和do_item_unlink可以看到  
  22.         //其内部也会锁住cache_lock锁.  
  23.         mutex_lock(&cache_lock);  
  24.   
  25.         ...//这里是迁移一个桶的数据到新哈希表  
  26.   
  27.         //遍历完一个桶的所有item后，就释放锁  
  28.         mutex_unlock(&cache_lock);  
  29.         item_unlock_global();//释放全局锁  
  30.   
  31.   
  32.         if (!expanding) {//不再需要迁移数据了。  
  33.             /* finished expanding. tell all threads to use fine-grained(细粒度的) locks */  
  34.             //进入到这里，说明已经不需要迁移数据(停止扩展了)。  
  35.             //告诉所有的workers线程，访问item时，切换到段级别的锁。  
  36.             //会阻塞到所有workers线程都切换到段级别的锁  
  37.             switch_item_lock_type(ITEM_LOCK_GRANULAR);  
  38.               
  39.             slabs_rebalancer_resume();  
  40.             /* We are done expanding.. just wait for next invocation */  
  41.             mutex_lock(&cache_lock);  
  42.             started_expanding = false; //重置  
  43.   
  44.             //挂起扩展线程，直到别的线程插入数据后发现item数量已经到了1.5倍哈希表大小，  
  45.             //此时调用别的线程调用assoc_start_expand函数，该函数会调用pthread_cond_signal  
  46.             //唤醒扩展线程  
  47.             pthread_cond_wait(&maintenance_cond, &cache_lock);  
  48.             /* Before doing anything, tell threads to use a global lock */  
  49.             mutex_unlock(&cache_lock);  
  50.             slabs_rebalancer_pause();  
  51.   
  52.             //从maintenance_cond条件变量中醒来，说明又要开始扩展哈希表和迁移数据了。  
  53.             //迁移线程在迁移一个桶的数据时是锁上全局级别的锁.  
  54.             //此时workers线程不能使用段级别的锁，而是要使用全局级别的锁，  
  55.             //所有的workers线程和迁移线程一起，争抢全局级别的锁.  
  56.             //哪个线程抢到了，才有权利访问item.  
  57.             //下面一行代码就是通知所有的workers线程，把你们访问item的锁切换  
  58.             //到全局级别的锁。switch_item_lock_type会通过条件变量休眠等待，  
  59.             //直到，所有的workers线程都切换到全局级别的锁，才会醒来过  
  60.             switch_item_lock_type(ITEM_LOCK_GLOBAL);  
  61.             mutex_lock(&cache_lock);  
  62.             assoc_expand();//申请更大的哈希表,并将expanding设置为true  
  63.             mutex_unlock(&cache_lock);  
  64.         }  
  65.     }  
  66.     return NULL;  
  67. }  

 

        眼尖的读者可能还看到了mutex_lock(&cache_lock)和slabs_rebalancer_resume()。不错，这又是对两个锁进行加锁处理。为什么要加这两个锁呢？是因为除了worker线程外还有其他一些线程，这些线程会操作LRU队列和哈希表。但这些线程没有像worker线程那样，可以被通知。所以只能再使用另外的大锁。当然这些线程大部分时间都是在休眠，对性能不会影响太大。由于涉及其他线程，本篇博文也是不会进一步进行讲解这两个锁。

 

 

 

引用计数：

 

为何需要引用计数：

 

        读者如果对C++的shared_ptr有所了解，那会更容易看懂接下来的内容。因为shared_ptr也用到引用计数的概念。

        为了保证线程安全，在访问和操作一个item时就必须加锁。而加锁就必然会导致性能的下降。如果在处理读操作的一开始就加锁，直到处理完读操作才解锁(即全程加锁)，那么对于一些热门数据将难于进行更新操作(也就是写操作)。这是因为对于热门数据有读操作会相当频繁，写操作将迟迟得不到执行。如果不全程加锁，那么又会出现一个worker线程在读一个item，而另外一个worker线程在删除这个item。如果这个item被删除了，那么正在读的item就操作一个非法的item。为了性能和处理这种情况，memcached使用引用计数技术。这里的引用计数C++的智能指针shared_ptr原理是一样的。当没有线程在引用这个item后，就会删除这个item(实际是将内存归还给slab分配器)。

 

        memcached为了使用引用计数技术，在item结构体定义了一个refcount成员，用于记录这个item被引用(被worker线程占用)的总数。当然增加和减少item的引用计数都必须是原子操作。为此，memcached定义了两个函数。

[cpp] view plain copy
 
 在CODE上查看代码片派生到我的代码片
  1. unsigned short refcount_incr(unsigned short *refcount) {  
  2. #ifdef HAVE_GCC_ATOMICS  
  3.     return __sync_add_and_fetch(refcount, 1);  
  4. #elif defined(__sun)  
  5.     return atomic_inc_ushort_nv(refcount);  
  6. #else  
  7.     unsigned short res;  
  8.     mutex_lock(&atomics_mutex);  
  9.     (*refcount)++;  
  10.     res = *refcount;  
  11.     mutex_unlock(&atomics_mutex);  
  12.     return res;  
  13. #endif  
  14. }  
  15.   
  16. unsigned short refcount_decr(unsigned short *refcount) {  
  17. #ifdef HAVE_GCC_ATOMICS  
  18.     return __sync_sub_and_fetch(refcount, 1);  
  19. #elif defined(__sun)  
  20.     return atomic_dec_ushort_nv(refcount);  
  21. #else  
  22.     unsigned short res;  
  23.     mutex_lock(&atomics_mutex);  
  24.     (*refcount)--;  
  25.     res = *refcount;  
  26.     mutex_unlock(&atomics_mutex);  
  27.     return res;  
  28. #endif  
  29. }  
  30.   
  31. //refcount_incr(&it->refcount);一般是这样调用的  
  32. // refcount_decr(&it->refcount)  

 

        如果不懂__sync_add_and_fetch和__sync_sub_and_fetch，那么赶紧谷歌之。因为它们是比较重要的函数，可以用来制作无锁队列。这两个函数都会返回操作后的值。

 

怎么使用引用计数：

 

        当然即使有了引用计数还是需要加锁的。因为在获取item和增加引用计数这一间隔，可能有其他线程把这个item给删除了。所以一般流程是这样：worker线程先加锁，然后获取item，之后增加这item的引用计数，最后释放锁。此时worker线程就占有了这个item，其他worker线程在执行删除操作时必须检测这个item的引用计数是否为0，也就是检查是否还有其他worker线程在使用(引用)这个item。下面举一个例子。        

[cpp] view plain copy
 
 在CODE上查看代码片派生到我的代码片
  1. item *item_get(const char *key, const size_t nkey) {  
  2.     item *it;  
  3.     uint32_t hv;  
  4.     hv = hash(key, nkey);  
  5.     item_lock(hv);  
  6.     it = do_item_get(key, nkey, hv);  
  7.     item_unlock(hv);  
  8.     return it;  
  9. }  
  10.   
  11.   
  12. /** wrapper around assoc_find which does the lazy expiration logic */  
  13. //调用do_item_get的函数都已经加上了item_lock(hv)段级别锁或者全局锁  
  14. item *do_item_get(const char *key, const size_t nkey, const uint32_t hv) {  
  15.     item *it = assoc_find(key, nkey, hv);//assoc_find函数内部没有加锁  
  16.       
  17.     if (it != NULL) {//找到了，此时item的引用计数至少为1  
  18.         refcount_incr(&it->refcount);//线程安全地自增一  
  19.         ...  
  20.     }  
  21.   
  22.     ...  
  23.   
  24.     return it;  
  25. }  


        处理get命令时就会调用上面那些代码。整个流程就像刚才说的那样。当然worker线程最后还需要减少这个item的引用计数。对于get命令来说，最后会调用item_remove命令减少item的引用计数。是不是觉得这里调用一个名为remove函数很奇怪呢？看代码实现吧。

 

[cpp] view plain copy
 
 在CODE上查看代码片派生到我的代码片
  1. void item_remove(item *item) {  
  2.     uint32_t hv;  
  3.     hv = hash(ITEM_key(item), item->nkey);  
  4.   
  5.     item_lock(hv);  
  6.     do_item_remove(item);  
  7.     item_unlock(hv);  
  8. }  
  9.   
  10. void do_item_remove(item *it) {  
  11.       
  12.     assert((it->it_flags & ITEM_SLABBED) == 0);  
  13.     assert(it->refcount > 0);  
  14.   
  15.     if (refcount_decr(&it->refcount) == 0) {//引用计数等于0的时候归还  
  16.         item_free(it);//归还该item给slab分配器  
  17.     }  
  18. }  

 

 

 

        可以看到，这是因为减少一个item的引用数可能要删除这个item。为什么呢？考虑这样的情景，线程A因为要读一个item而增加了这个item的引用计数，此时线程B进来了，它要删除这个item。这个删除命令是肯定会执行的，而不是说这个item被别的线程引用了就不执行删除命令。但又肯定不能马上删除，因为线程A还在使用这个item，此时memcached就采用延迟删除的做法。线程B执行删除命令时减多一次item的引用数，使得当线程A释放自己对item的引用后，item的引用数变成0。此时item就被释放了(归还给slab分配器)。

 

        有一点要注意：当一个item插入到哈希表和LRU队列后，那么这个item就被哈希表和LRU队列所引用了。此时，如果没有其他线程在引用这个item的话，那么这个item的引用数为1(哈希表和LRU队列看作一个引用)。所以一个worker线程要删除一个item(当然在删除前这个worker线程要占有这个item)，那么需要减少两次item的引用数，一次是减少哈希表和LRU队列的引用，另外一次是减少自己的引用。所以经常能在代码中看到删除一个item需要调用函数do_item_unlink (it, hv)和do_item_remove(it)这两个函数。

 

tail_repair_time：

 

        考虑这样的情况:某个worker线程通过refcount_incr增加了一个item的引用数。但由于某种原因(可能是内核出了问题)，这个worker线程还没来得及调用refcount_decr就挂了。此时这个item的引用数就肯定不会等于0，也就是总有worker线程占用着它.但实际上这个worker线程早就挂了。所以对于这种情况需要修复。修复也很多简单：直接把这个item的引用计数赋值为1。

        根据什么判断某一个worker线程挂了呢?首先在memcached里面，一般来说，任何函数都的调用都不会耗时太大的，即使这个函数需要加锁。所以如果这个item的最后一次访问时间距离现在都比较遥远了，但它却还被一个worker线程所引用，那么就几乎可以判断这个worker线程挂了。在1.4.16版本之前，这个时间距离都是固定的为3个小时。从1.4.16开就使用settings.tail_repair_time存储时间距离，可以在启动memcached的时候设置，默认时间距离为1个小时。现在这个版本1.4.21默认都不进行这个修复了，settings.tail_repair_time的默认值为0。因为memcached的作者很少看到这个bug了，估计是因为操作系统的进一步稳定。上面的版本说明来自链接1和链接2。

        上面进行了理论说明，下面看一下memcached实现吧。

[cpp] view plain copy
 
 在CODE上查看代码片派生到我的代码片
  1. item *do_item_alloc(char *key, const size_t nkey, const int flags,  
  2.                     const rel_time_t exptime, const int nbytes,  
  3.                     const uint32_t cur_hv) {  
  4.     uint8_t nsuffix;  
  5.     item *it = NULL;  
  6.     char suffix[40];  
  7.     //要存储这个item需要的总空间  
  8.     size_t ntotal = item_make_header(nkey + 1, flags, nbytes, suffix, &nsuffix);  
  9.     if (settings.use_cas) {  
  10.         ntotal += sizeof(uint64_t);  
  11.     }  
  12.   
  13.     //根据大小判断从属于哪个slab  
  14.     unsigned int id = slabs_clsid(ntotal);  
  15.   
  16.     item *search;  
  17.     item *next_it;  
  18.   
  19.     search = tails[id];  
  20.     for (;search != NULL; search=next_it) {  
  21.         next_it = search->prev;  
  22.   
  23.         uint32_t hv = hash(ITEM_key(search), search->nkey);  
  24.           
  25.         /* Now see if the item is refcount locked */  
  26.         if (refcount_incr(&search->refcount) != 2) {  
  27.   
  28.             refcount_decr(&search->refcount);  
  29.             /* Old rare bug could cause a refcount leak. We haven't seen 
  30.              * it in years, but we leave this code in to prevent failures 
  31.              * just in case */  
  32.             if (settings.tail_repair_time &&//启动了检测  
  33.                     search->time + settings.tail_repair_time < current_time) {//在这个时间距离内都没有访问过  
  34.                 search->refcount = 1;//释放线程对item的引用  
  35.                 do_item_unlink_nolock(search, hv);//这里会把item从哈希表和LRU队列中删除并将引用计数减一  
  36.             }  
  37.             continue;  
  38.         }  
  39.   
  40.         ...  
  41.     }  
  42.   
  43.     ...  
  44.   
  45. }     


        代码中的settings.tail_repair_time指明有没有开启这种检测，默认是没有开启的(默认值等于0)。可以在启动memcached的时候通过-o tail_repair_time选项开启。具体可以参考《memcached启动参数详解以及关键配置的默认值》。

posted on 2016-06-05 10:41  c++kuzhon  阅读(230)  评论(0)    收藏  举报

导航