memcache不会释放内存，而是重新利用。
在缓存的清除方面，memcache是不释放已分配内存。当已分配的内存所在的记录失效后，这段以往的内存空间，memcache只会重复利用。
memcached的内存回收机制不是说你设置的key到了生命周期就自动从内存中清除的，这个时候必须有一个新的对象入驻请求这个大小的chunk或者
这个过期的对象被get的时候才会清除。
那当所有给memcache的内存都被占用了，这个时候，memcache有两个设置，要么报错，要么，就是用 LRU方法，把last recently
used的数据清除出去，也就是删除近段时间最少使用的同规格chunk。
这个时候就会引发应外一个问题，就是当你chunk大小设置不合理的时候，比如slab20
chunk大小非常大，一开始占用了很多内存，但是之后不论是否过期，不被再次利用到的时候就一直处于内存中，这样，当比较小的slab1中的chunk
满了，也没有内存新建slab并分割和slab1同样规格的chunk的时候，memcached就要启动LRU，来清理这个slab下的数据。那这种情
况就会造成在内存的极大程度浪费和cache命中率下降，是某些关键性的数据总是在内存中进进出出，得不到持久的保存。
这个时候我们可以调整factor参数，让chunk的大小达到我们的需要，这个需要根据业务来做。
那slab数量，growth factor大小，LRU频率以及空间浪费情况可以估计出来如下结果：
growth factor↑ slab数量 ↓ LRU频率↓ 空降浪费↑
growth factor↓ slab数量 ↑ LRU频率↑ 空降浪费↓
关于LRU
我们知道c++里分配内存有两种方式，预先分配和动态分配，显然，预先分配内存会使程序比较快，但是它的缺点是不能有效利用内存，而动态分配可以有效利用
内存，但是会使程序运行效率下降，memcached的内存分配就是基于以上原理，显然为了获得更快的速度，有时候我们不得不以空间换时间。
我启动一个memcached进程，占用内存100m，再打开telnet，telnet localhost
11211，连接上memcache之后，输入stats slabs，回车，出现如下数据：
STAT 1:chunk_size 80
STAT 1:chunks_per_page 13107
STAT 1:total_pages 1
STAT 1:total_chunks 13107
STAT 1:used_chunks 13107
STAT 1:free_chunks 0
STAT 1:free_chunks_end 13107
STAT 2:chunk_size 100
STAT 2:chunks_per_page 10485
STAT 2:total_pages 1
STAT 2:total_chunks 10485
STAT 2:used_chunks 10485
STAT 2:free_chunks 0
STAT 2:free_chunks_end 10485
STAT 3:chunk_size 128
STAT 3:chunks_per_page 8192
STAT 3:total_pages 1
STAT 3:total_chunks 8192
STAT 3:used_chunks 8192
STAT 3:free_chunks 0
STAT 3:free_chunks_end 8192
以上就是前3个slab得详细信息
chunk_size表示数据存放块得大小，chunks_per_page表示一个内存页page中拥有得chunk得数
量，total_pages表示每个slab下page得个数。total_chunks表示这个slab下chunk得总数（＝total_pages *
chunks_per_page），used_chunks表示该slab下已经使用得chunk得数量，free_chunks表示该slab下还可以
使用得chunks数量。
从上面得示例slab
1一共有1m得内存空间，而且现在已经被用完了，slab2也有1m得内存空间，也被用完了，slab3得情况依然如此。
而且从这3个slab中chunk得size可以看出来，第一个chunk为80b，第二个是100b，第3个是128b，基本上后一个是前一个得
1.25倍，但是这个增长情况我们是可以控制得，我们可以通过在启动时得进程参数 –f来修改这个值，比如说 –f
1.1表示这个增长因子为1.1，那么第一个slab中得chunk为80b得话，第二个slab中得chunk应该是80*1.1左右。
解释了这么多也该可以看出来我遇到得问题得原因了，如果还看不出来，那我再补充关键的一句：memcached中新的value过来存放的地址是
该value的大小决定的，value总是会被选择存放到chunk与其最接近的一个slab中，比如上面的例子，如果我的value是80b，那么我这
所有的value总是会被存放到1号slab中，而1号slab中的free_chunks已经是0了，怎么办呢，如果你在启动memcached的时候
没有追加-M（禁止LRU，这种情况下内存不够时会out of
memory），那么memcached会把这个slab中最近最少被使用的chunk中的数据清掉，然后放上最新的数据。这就解释了为什么我的内存还有
40%的时候LRU就执行了，因为我的其他slab中的chunk_size都远大于我的value，所以我的value根本不会放到那几个slab中，
而只会放到和我的value最接近的chunk所在的slab中(而这些slab早就满了，郁闷了)。这就导致了我的数据被不停的覆盖，后者覆盖前者。
问题找到了，解决方案还是没有找到，因为我的数据必须要求命中率时100%，我只能通过调整slab的增长因子和page的大小来尽量来使命中率
接近100%，但是并不能100%保证命中率是100%（这话怎么读起来这么别扭呢，自我检讨一下自己的语文水平），如果您说，这种方案不行啊，因为我的
memcached server不能停啊，不要紧还有另外一个方法，就是memcached-tool，执行move命令，如：move 3
1，代表把3号slab中的一个内存页移动到1号slab中，有人问了，这有什么用呢，比如说我的20号slab的利用率非常低，但是page却又很多，
比如200，那么就是200m，而2好slab经常发生LRU，明显page不够，我就可以move 20
2，把20号slab的一个内存页移动到2号slab上，这样就能更加有效的利用内存了（有人说了，一次只移动一个page，多麻烦啊？ahuaxuan
说，还是写个脚本，循环一下吧）。
有人说不行啊，我的memcache中的数据不能丢失啊，ok，试试新浪的memcachedb吧，虽然我没有用过，但是建议大家可以试试，它也使利用
memcache协议和berkeleyDB做的（写到这里，我不得不佩服danga了，我觉得它最大的贡献不是memcache
server本身，而是memcache协议），据说它被用在新浪的不少应用上，包括新浪的博客。
补充，stats
slab命令可以查看memcached中slab的情况，而stats命令可以查看你的memcached的一些健康情况，比如说命中率之类的，示例如下：
STAT pid 2232
STAT uptime 1348
STAT time 1218120955
STAT version 1.2.1
STAT pointer_size 32
STAT curr_items 0
STAT total_items 0
STAT bytes 0
STAT curr_connections 1
STAT total_connections 3
STAT connection_structures 2
STAT cmd_get 0
STAT cmd_set 0
STAT get_hits 0
STAT get_misses 0
STAT bytes_read 26
STAT bytes_written 16655
STAT limit_maxbytes 104857600
从上面的数据可以看到这个memcached进程的命中率很好，get_misses低达0个，怎么回事啊，因为这个进程使我刚启动的，我只用
telnet连了一下，所以curr_connections为1，而total_items为0，因为我没有放数据进去，get_hits为0，因为我
没有调用get方法，最后的结果就是misses当然为0，哇哦，换句话说命中率就是100%，又yy了。
该到总结的时候了，从这篇文章里我们可以得到以下几个结论：
结论一，memcached得LRU不是全局的，而是针对slab的，可以说是区域性的。
结论二，要提高memcached的命中率，预估我们的value大小并且适当的调整内存页大小和增长因子是必须的。
结论三，带着问题找答案理解的要比随便看看的效果好得多。
参考：http://ahuaxuan.iteye.com/blog/225692