＜/br＞

＜/br＞

1 requestId 2 type 3 content

然后 content又会根据命令的类型,被解析成 key 和 其它参数,中间的一些复制过程都会产生很多新的String

2 hash里面的entry对象,这个对象只有在有新数据加入的时候才会被生成

答案是不能,因为cache类型的应用本质上大部分对象就是会存储很久的,从这个主线上来说老年代应该尽可能的大才对;

所以思考得出,那么只可能尽量减少这些临时对象的生成;

进一步的,String本身是immutable的,这个特点有数不清的好处,但是在这里不适用,第一导致无法像redis那样对字符串自己进行操作,第二,没有办法将对象池化(不能修改内容所以不能复用)

<li>1 所有String都要替换,那么只能从netty bytebuf那里开始就不产生String,同时要实现在不new 新对象的情况下将RedisString从大对象拆分成小对象;另外不能使用String,那么fastJson也没有办法直接使用了,所以还需要考虑怎么自定义简单协议进行parse;

<li>2 RedisString本身是可以修改的,这确实也导致一些诡异的bug,根本原因就是还有对象在引用它,但是缺把它回收,这会导致各种奇怪问题: 死锁,对象被破坏.解析错误等等;所以分配和释放的时机要非常的小心才可以;

<li> 3 分配的策略,对象池的分配算法比内存池简单,因为对象的大小一般是一组固定的大小;但是要考虑一些问题:

对象的大小设置为多少合适?

对象池的大小需要动态的变化,怎么设计变化的策略?

对象释放的时候有线程竞争,怎么保证性能和安全?

如何为一个分配的请求快速定位到合适的对象大小?

如何设计一套合理的接口,将对象池本身逻辑抽象出来,这样实现其它的池化对象也相对简单清晰?

下面就简单描述一下解决了哪些问题,和解决的思路:

<li>1 替换所有String,体力活,要求是细心不出错,替换的时候还要重写hashcode,equal,parseInt等各种方法

＜/br＞

<li>2 如何设计一套接口体系,首先设计AbstractPooledObject这个抽象类,然后声明好length(),size(),newInstance(),release(),等抽象方法;然后设计一个AbstractObjectPool这样的抽象类,这个抽象类主要实现对象池,它具有很多组不同大小的对象container,分配的时候就迅速定位到合适大小的container,释放的时候也一样;如果找不到合适大小的container或者说没有对象可以分配,那么就调用newInstance来分配新的对象;

＜/br＞

<li>3 怎么设计策略?

＜/br＞

<li>4 怎么迅速定位?

我们将设计对象池的长度为一系列长度 s1,s2,s3....sn,然后在中间插入 一些 2^n大小的数据,这样给定一个len,就利用JDK里面的办法先定位到第一个大于len的2^k,然后往回找一下,看哪个是第一个大于len且在我们初始化好的lengthTable里面,返回对应的index即可; 如果该池没有启用或者没有合适对象,可以尝试去更大的对象池找一下,但是不得超过所需的两倍大小;

释放的时候也是一样的策略,关键是找到一个合适的长度s,使得 s <= len(注意这里和分配的要求恰恰相反,可以思考下为什么),

然后尝试将数据返回对应的容器,如果满了就算了;

<li>5 怎么确保释放和分配线程安全？

首先要考虑异步线程allocate和release会怎么样? 首先我们当然可以使用并发容器来控制分配或者加锁,但是这对性能的损耗比较大，所以一个办法是: 只在主线程进行对象池的分配,事实上目前的异步线程没有要分配对象的需求,只有释放的需求;

释放的时候将数据放到一个并发队列里面,每过一段时间主线程就从这个队列统一将数据放到真正的对象池里面;

这样就不会影响太多主线程分配和释放的性能;(还可以优化,就是用普通队列 lazyRemovedQue,但是异步线程每次放到一个线程私有的队列里面，然后定时将这个队列放入lazyRemovedQue,这样就只要加锁一次,然后主线程也只要加锁一次从lazyRemovedQue里面移动)

另外为了性能,就只需要将这个对象池的容器使用数组实现的普通Queue即可(目前是手动实现一个,因为功能比较少,也可以用ArrayDeque)这样缓存更加友好;性能更好

<li>6 怎么保证一个线程里面release的时候是安全的?

首先明确问题是什么: 假设我有一个key(RedisString),这个key在什么时候应该被释放呢? 有这些场景:

1 get请求,只读请求,显然可以释放

2 set请求,如果这个ke已经重复了,那么可以直接释放,同时还可以释放老的value

难点在于: 我们如何保证这个RedisString释放的时候下面没有使用了? 比如如果现在处于 rehash的状态,那么

我们有这样的操作 map.put(key,val); rehashmap.remove(key); 那么如果你在RedisHashMap这个层次上操作,就没有办法知道

上层的情况(也不应该知道上层的调用逻辑); 有时候我们还利用key获取了EasyLock,如果你在里面就释放,会导致接下来获取的lock不正确从而产生死锁;

总结一下 Command -> RedisDb -> RedisDict -> RedisConcurrentHashMap -> RedisHashMap

-> RedisHashMap

ExpireHelper -> RedisDict也使用到了对应的调用链

我们要找到一个合适的位置释放该释放的东西,避免提前释放的错误;

＜/br＞

目前暂时先手动把逻辑写对,但是最好的做法将所有的释放集中到一个层面来管理:

＜/br＞