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