DefaultInvokeFuture#TimeoutScanner优化

[fengjiachun]

目前是遍历chm来查找超时future, 有一定竞争

[scanry]

那么我们再回到问题的本质:就是删除异步调用future。也就是在客户端调用服务端客户端没有收到服务响应，那么超时后uture会一直占用cache。 如果在发起调用后将要监听的异步future票据插入时间轮队列的时间O(lgn)接收不了的话，那么还可以加一层普通FIFO队列，然后单独一个守护线程处理这个future票据将它插入时间轮队列，这样发起调用线程的时间花费那么就变成O(1)。 这样的话是不是也减少了发起调用前将future插入cache 同 扫描cache中过期future线程 的 锁竞争？

[Coneboy-k]

使用 类似于netty 的Channel idle 的检测机制（HashedWheelTimer）如何？

[fengjiachun]

@Coneboy-k 不错, 是计划用hash时间轮试一试

[fengjiachun]

@scanry @Coneboy-k 对于队列容量是个考验, 因为future只有超时的情况才会被移除

[fengjiachun]

future在chm中的时候只要响应回复了就可以移除

[Coneboy-k]

我的CHM 存future不变。 增加一个Futur超时管理的Service 。 Service的管理的超时对象，是继承于AbsTimerItem 。 其中 AbsTimerItem有超时读和写的方法，最终在Service中可以封装成接口暴露给存future的CHM。这样写法耦合度很低。不需要改变太多代码 其中对应关系为 Service：timerObj：future=M:1:1

PoolItemService.java https://gist.github.com/Coneboy-k/9c7496abc45012f6943d2a94ffcfa93a
AbsTimerItem.java https://gist.github.com/Coneboy-k/4c0cc857425e32f80a8a0bf1739d28be

如果思路没问题，我尝试提交个PR 上面的还是参考大佬 netty idle的检测实现的。 :-)

[fengjiachun]

经 @scanry 的提醒, 超时队列只存放invokeId, 然后再回到DefaultInvokeFuture#roundFutures中查找future就可以了

[fengjiachun]

忘了关联到这个issue上了

[fengjiachun]

@Coneboy-k 你给的链接打不开啊

[Coneboy-k]

@fengjiachun gist.github.com 貌似被墙了。挂个代理试试？