1.
在官网还是哪儿，我看到了一句关于代码中哈希表的注释:
具体记不清楚了，大概有个单词是coarse,意识是说，该哈希表的锁粒度实在是太粗了，以后再细化。
确实，非常粗，多个工作线程对它的互斥竞争比较强烈，到处都是对cache_lock的上锁解锁。
2.解决方案：
首先，想把哈希表拆成多个小表，怎么拆呢？
嗯，看一下工作线程；
之前说过，工作线程将IO与逻辑糅合在了一起。
尝试剥离它们把。
我的设计方案如下：
主线程：
负责所有IO，它就是网络线程。包括非阻塞accept接收新连接，并管理新连接的网络事件。
当新连接上有客户端发来的请求时，主线程做少许的逻辑：仅仅是分隔每一个请求，并计算该请求的key的哈希值，
假如工作线程数目为4，那么对所得到的哈希值%4，投递给相应的工作线程；
投递这一操作可以设计成无锁的，没太多难度，生产者消费者问题的典型应用。
工作线程：
它变成纯逻辑线程，且拥有一个独立的哈希表。
不知道新版本memcached会采用什么方法，拭目以待。
3. slab内存池
该内存池的锁粒度仍然很粗。考虑到竞争强度不高，改不改也无所谓。