<
从版本< 21.1 >
xu yang编辑
在2022/04/27 14:00上
到版本
xu yang编辑
在2022/04/27 14:05上
修改评论 该版本没有评论

Summary

Details

Page properties
Content
... ... @@ -46,6 +46,8 @@
46 46  {{/plantuml}}
47 47  
48 48  
49 +先说明,redis中,过期时间等信息是单独放在一个table中存储的,因为不是所有key都设有过期时间,放在一起存储会额外增加存储成本。
50 +
49 49  expireIfNeeded方法用来判断一个key是否过期
50 50  返回1,说明已经过期
51 51  返回0,说明数据没有过期
... ... @@ -95,7 +95,6 @@
95 95  {{/plantuml}}
96 96  
97 97  
98 -先说明,redis中,过期时间等信息是单独放在一个table中存储的,因为不是所有key都设有过期时间,放在一起存储会额外增加存储成本。
99 99  再看同步删除dbSyncDelete的策略
100 100  
101 101  {{plantuml}}
... ... @@ -119,11 +119,12 @@
119 119  @enduml
120 120  {{/plantuml}}
121 121  
122 -关于dictDelete这里就先不画图了,讲一下主要的实现代码吧。
123 -java中的map或者说hashmap对应的就是redis中的dict结构,区别是jdk在1.8版本之后使用拉链转红黑树的方式处理哈希冲突,而redis使用的方法还是拉链存储法,对应着jdk1.7。
124 -在redis中存在内存常量池的概念,主要是对应对应字符串这种结构设计的,对于相同的字符串使用同一块内容空间。
123 +
124 +关于dictDelete这里就先不画图了,讲一下主要的实现逻辑吧。
125 +可以大概认为,java中hashmap结构对应的就是redis中的dict结构,区别是jdk在1.8版本之后使用拉链转红黑树的方式处理哈希冲突,而redis使用的方法还是拉链存储法,对应着jdk1.7。
126 +在redis中也存在内存常量池的概念,主要为是对应字符串/数字这种结构设计的,对于相同的字符串使用同一块内存空间。
125 125  这样的结构在删除key和value的时候就存在一个额外的问题,如果我直接free掉这块内存,那么其他key和value指向这块内存的读写就会存在异常。
126 -redis为了避免这样的问题,在dict删除一个key的过程实际是将dict中的对应的key的指针删除,然后根据实际调用场景判断是否要清理key和value占用的那块内存。
128 +redis为了避免这样的问题,在dict删除一个key的过程实际是将dict中的对应的key的指针删除,然后然后在根据情况(内存是否被共享)再决定是否去free内存空间
127 127  
128 128  
129 129  再看异步删除dbAsyncDelete的策略