redis sds结构的一点思考

      		 嗷嗷嗷嗷，保持思考，保持智障。哈哈哈。

redis 结构很多，但是最基础的是简单字符串，然后redis里面叫做SDS。
从Java的角度看这个事情超级简单。还需要设计吗？不就是多了一个类吗？有自己的length。可以自动扩展，这在我们java里面不是so easy的事情吗？
学习是螺旋式上升。
其实这个角度不对。你以前看问题是直接从一个java去设计程序，java，去设计程序有一个很大的问题是在于有JVM，JVM很大程度上让程序猿感受不到里面的思想。

OK，假如没有JVM，数组方式非常原始。现在我有一个字符串 是 “1234”
怎么设计？
我肯定是首先 new int[4]。
OK，现在"1234" 我要变成 12345，我肯定只能
new int[5] ,然后赋值新值，将老值给释放掉。
释放掉的时候，顺便释放掉内存。

这里会出现一个问题。就是释放内存的时候，需要花费时间。
一般来说，可能无感。但是假如从高并发或者吞吐量要求巨高。那么久很蛋疼了。

也就是面试经常说的jvm调优，那么调优的本质就是要求速度更快，服务器用的资源更少。
用少的资源，创造更好的价值。闲话少说。回归正题。

频繁的的释放内存，会造成GC。不管是JVM还是.net内存机制或者任何其他。
只要不是黑科技，天顶星科技。用了内存，就要释放。释放就要占用时间。

那么redis，怎么做的？预留空间。比如你你的字符串是"1234"那么给到的位置new int[6],预留内存有什么好处了？“1234”=>“123456”,不需要加内存，不需要重新申请内存区域。

这里出现了2个问题。
1.当字符串是 “1234”=>“1"了？岂不是爆炸
2.当字符串是"1234”=“123456789”？岂不是爆炸。

问题1：爆炸原因肯定是因为内存使用率过小，比如我申请了6个bytes，但是最终只用了1bytes,并且一个Bytes，我可能从今年的1月用到明年的12月，这岂不是，浪费5个Bytes 2年，这种设计，岂不是垃圾到爆炸。

哦吼。redis的设计非常精巧。我们都知道redis的数据
驱逐数据是有LRU策略。
这里叫做惰性回收，用来专门减少内存分配。
有关键的时候，会自动把内存给回收掉的。（吐槽，这里没看过更详细的设计源码，所以更具体我也不知道啦。）

然后其实以上从java的角度来看是没啥问题的。但是这是C，用的非常底层的结构，是不提供一些封装方法的。

所以它增加了2个字段，一个字段是len（已经使用字符串长度） free(空余字符串长度)。
用来做一个查询，因为以前是便利查询到截取数组字段’\0‘才知道长度。

将操作改为O(1)。

问题2：这里其实并不爆炸。因为字符串从客观的角度讲，大规模变化特长并不是一个很高频的做法。