如履薄冰：Redis懒惰删除的巨大牺牲

异步线程需要对任务队列进行轮询处理，依次从链表表头摘取元素逐个处理。摘取元素的时候也需要加锁，摘出来之后再解锁。如果一个元素都没有，它需要等待，直到主线程来唤醒它继续工作。

// 异步线程执行逻辑  
void *bioProcessBackgroundJobs(void *arg) {  
...  
    pthread_mutex_lock(&bio_mutex[type]); // 先加锁  
    ...  
    // 循环处理  
    while(1) {  
        listNode *ln;  
        /* The loop always starts with the lock hold. */  
        if (listLength(bio_jobs[type]) == 0) {  
            // 对列空，那就睡觉吧  
            pthread_cond_wait(&bio_newjob_cond[type],&bio_mutex[type]);  
            continue;  
        }  
        /* Pop the job from the queue. */  
        ln = listFirst(bio_jobs[type]); // 获取队列头元素  
        job = ln->value;  
        /* It is now possible to unlock the background system as we know have  
         * a stand alone job structure to process.*/  
        pthread_mutex_unlock(&bio_mutex[type]); // 释放锁  
        // 这里是处理过程，为了省纸，就略去了  
        ...  
        // 释放任务对象  
        zfree(job);  
        ...  
        // 再次加锁继续处理下一个元素  
        pthread_mutex_lock(&bio_mutex[type]);  
        // 因为任务已经处理完了，可以放心从链表中删除节点了  
        listDelNode(bio_jobs[type],ln);  
        bio_pending[type]--; // 计数减 1  
    } 

研究完这些加锁解锁的代码后，笔者开始有点担心主线程的性能。我们都知道加锁解锁是一个相对比较耗时的操作，尤其是悲观锁最为耗时。如果删除很频繁，主线程岂不是要频繁加锁解锁。

所以这里肯定还有优化空间，Java 的 ConcurrentLinkQueue 就没有使用这样粗粒度的悲观锁，它优先使用 cas 来控制并发。那就让我们就期待 Redis 在未来的版本里对它进一步改造优化吧！

（编辑：拼字网 - 核心网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!