static PriorityList[] expires;
 PriorityList则是对优先队列的封装
这样每来一个过期事件,我们就判断过期时间是不是小于一个规定的时间,比如2个小时;
如果小于就可以直接塞到对应的`PriorityList`里面,具体：

            if(delay < slotNum * 4){
            /* 如果是那种延迟很大的过期key,就不放在定时轮里面,而是采用原来redis的随机抽样做法
            *  因为如果过期时间很长,就会导致定时轮里面存储太多数据,从而导致插入变慢,而且占用太多内存太久
            */
            int index = (int)((now + delay ) & (slotNum - 1));// 计算应该放到的index
            PriorityList slot = expires[index];
            slot.add(new ExpireObject(key,now + delay));
            System.out.println("add index");
        }

利用反射+Unsafe,拿到HashMap里面对应的table(Node[]),然后还是利用unsafe计算出Node的next元素,这样就可以像Redis一样进行遍历了,当然这不是一个好的办法,和JDK具体实现耦合在了一起,只是不得已的办法,最好的办法还是自己重写一个HashMap,不用JDK的那个。

从RedisHashMap衍生两种类型,第一个是普通的HashMap,另外一个是支持并发的HashMap
如果需要异步线程的支持,我们就在主线程里面将普通的Map替换成ConcurrentRedisHashMap
像这样:
	    public static void converMapToConcurrent(){
        if(!RedisMap.holdByAnother()) {
            RedisConcurrentHashMap<String,RedisObject> cmap = new RedisConcurrentHashMap<>(RedisMap);
            cmap.incrRef();
            RedisMap = cmap;
            //RedisMap.get("1");
        }
    }

同时注意到异步线程对于PriorityList的add操作和主线程过期操作可能会有数据竞争,所以我们需要单独为一个PrioirtyList设置一个并发的版本,思路类似上面的Map,具体内容见:「ConcurrentPriorityList.class」

	实际上,最开始我使用的是JDK的HashMap,但是存在各种问题,你要在主动rehash的过程中防止hashMap自动扩容,要处理size的线程不安全,还要面对无法高效率的获取随机的值等问题。
	要绕过JDK的限制非常麻烦,而且关于自动扩容的问题, 非常难以限制,会导致线程安全的问题
	比如异步线程往新的map添加元素,同时主线程也将新的元素添加到·新的map,如果并发够大,
	完全可能产生新的map在扩容过程中再次扩容,这个时候导致分段锁失效等情况。

put: 只往新的map存,但是同时要删除老的map里面可能的key
remove: 先删老的map,再删新的map(否则存在线程安全)
get: 先查新的map,后查老的map  
什么时候执行这个逻辑:
	分两种情况来讨论,首先考虑扩容,这里把负载因子1作为分界线
	然后考虑缩容,这里把负载因子0.5作为分界限(缩容的时候还要考虑频率,限定为至少间隔1s)
	另外对于size比较小的rehash,就直接在主线程执行

	put的代码:
	 if(RedisServer.isCurrentThread()){
	            safePut(key,val);
	        }else{
	            if(!inRehashProgress()){
	                // 不扩容状态
	                greadLock();
	                safePut(key, val);
	                greadUnLock();
	            }else{
	                // 这里处于扩容状态， rehashMap != null
	                // 但是由于没有锁的保护,可能突然变成非扩容状态,rehashMap == NULL
	                // 所以 stopRehash只能在「没有异步线程的」
	                safePut(key,val);
	            }
	        }
	
	        // 这里有多种case 1 主线程扩容,当前字典可能是「普通状态」／「并发状态」
    // 2 异步线程扩容,且当前字典已经是扩容的状态
    // 3 异步线程扩容,当前字典一定是并发状态
    // 我们只在主线程切换状态,所以其它两个线程我们不执行
    if(RedisServer.isCurrentThread() && needGrowth(true)){
        startRehash(); // case2会直接被startRehash过滤
    }

遍历所有老的slot,将这些slot添加到新的map上面
关键点: 每一个slot都需要加锁来保证正确性
＜/br＞
 EasyLock lock = lockArr[index & (lockNum - 1)];
    lock.lock(); // 需要lock住固定的index
    Node node = map.table[index];
    int nodeNum = 0;
    while (node != null){
        // 进行rehash
        ++nodeNum;
        rehashMap.put(node.getKey(),node.getValue());// 自动加锁
        node = node.next;
    }
    map.table[index] = null;//所有的都设置为null,这样就成功将map本身给解决了,map本身的size也应该修改
    tmpSize.addAndGet(-nodeNum);
    lock.unlock();
   ＜/br＞ 

	  首先我们引入了一个新的中间层 `RedisDict`
	  这个东西负责 rehash操作和 普通RedisHashMap到RedisConcurrentHashMap的转换,这样对于使用RedisDict的操作就完全屏蔽了。
	  但是,对于rehash操作,由于存在突然变成rehash状态和突然从rehash状态结束两种变化,那么这个线程安全是必须要保证的。

两种策略: 1 延迟stopRehash的操作,所有的stopRehash操作只在没有异步线程持有当前RedisDict的时候才执行,这样就避免了上面说的问题。
			2 先检查是不是在主线程执行的这个操作,如果在主线程就不需要对检查 rehash状态加锁,因为所有对状态变化只发生在主线程。
再看一次put的代码,这里采取策略2:

 void safePut(K key, T val){
        if(inRehashProgress()){
            // 扩容状态
            rehashMap.put(key,val);
            map.remove(key);// 这一步是必要的
        }else {
            // 非扩容状态
            map.put(key,val);
        }
    }

if(RedisServer.isCurrentThread()){
	            safePut(key,val);
	        }else{
	           greadLock();
	            if(!inRehashProgress()){
	                // 不扩容状态
	                safePut(key, val);
	             }else{
	                // 这里处于扩容状态， rehashMap != null
	                // 但是由于没有锁的保护,可能突然变成非扩容状态,rehashMap == NULL
	                // 所以 stopRehash只能在「没有异步线程的」
	                safePut(key,val);
	            }
	             greadUnLock();
	        }

 public void remove(K key) {
    map.remove(key);
    if(inRehashProgress()) {// 1
        greadLock();
        if(inRehashProgress()){
            rehashMap.remove(key);
        }
        greadUnLock();
    }

    if(RedisServer.isCurrentThread() && needtrim(true)){
        startRehash();
    }
}    

由于map具有这样几个属性,「是否并发」,「是否正在扩容」,「被几个线程持有」,其中「被其它线程持有」一定意味这「处于并发状态」
所以停止rehash的时候,需要考虑一些情况,比如
如果被其它线程持有着(并发状态),那么不能立刻结束rehash状态,这本来是通过「读写自旋锁」来进行保证的, 但是我们可以再提高一点性能,如果该Dict被其它线程持有,那么会延后执行该Dict的stopRehash,这样就可以先执行其它任务而不是「自旋」

在开始rehash的时候,也要根据「是否已经处于并发状态」,「是否可以直接执行rehash」

死锁,注意到获取size的时候同样存在线程安全的问题,但是size加的是「readLock」,如果调用的上层恰好使用「writeLock」,就会导致死锁。所以还需要一个无锁版本的size

1 requestId 2 type 3 content
然后 content又会根据命令的类型,被解析成 key 和 其它参数,中间的一些复制过程都会产生很多新的String
  
2 hash里面的entry对象,这个对象只有在有新数据加入的时候才会被生成

	首先我们将对象池理解为一个管道,一边是流入的对象(release),一边是流出(allocate),那么我们取一段时间之内这两者的调和平均数作为对象池的大小,就可以比较好的适应需求; 所以需要进行统计,每次allocate的时候对申请对应大小的数组位置+1,release的时候也对对应大小的数组的位置+1; 这样就相当于统计一段时间之内分配次数和释放次数;
	 我们考虑这样一种情况: 将JavaRedis作为一个分布式的锁的实现,也就是set一下然后很快就释放掉;这种情况下中间有一个时间差delay,可以想到在delay结束之前,是不会有release被调用的,但是只要过了这个delay,那么就有数据被释放了,中间阶段都会达成一个平衡的状态;大概像下面一样:  
<li>allocate allocate ..................... allocate ........ allocate...   
<li>[------ delay(3s)--------] release release ..... release ......  	 
	当然中间可能存在一些波动,比如delay变化了,或者一段时间没有收到这样情况的请求;
	所以需要将统计的时间稍微扩大一点,变化平缓一点: 所以把这个数据当成一个时间序列我们进行加权:
	
allocateAccumulation[index] = allocateAccumulation[index] * scaleDown + allocateArray[index]
releaseAccumulation[index] = releaseAccumulation[index] * scaleDown + releaseArray[index]

	这样开启一个定时任务,每s运行一次,就可以得到过去一段时间里面 分配 和 释放的估计值,然后求调和平均数,得到这个大小下的对象池的估计大小;
	有了这个大小就可以实现各种策略了: 连续N次估计值大于threshold才分配对象,如果发现估计值大于当前的对象池大小,可以设计一套策略来调整大小;(比如大于原来的1.5倍就申请新的大小的对象池进行迁移)
	如果估计值太小,说明当前场景不适合对象池(分配对象也要开销的),所以可以适当减少对象池大小,连续N次这样就直接释放,但是
	如果又有新的分配需求,那么又满满将数据加回去(比如连续1024次不满足就释放对象池,设置这个值为-1024.如果有新的大量请求出现,那么就折半衰减负数,这样可以快速恢复到对象池分配的状态)