Time wheel implementation required

[wkgcass]

目前的定时任务是通过PriorityQueue维护的，考虑换成时间轮。

由于常见的TCP超时时间是15分钟（例如LVS），而UDP则更短，一般认为不会出现超过15分钟的定时任务

使用4层时间轮，每层32个元素。可以表示32^4=1048576 ms > 15 minutes。使用链表维护同一毫秒的定时任务列表。使用32是因为%操作可以优化为&操作

不需要考虑并发，时间事件的访问总是在eventloop里面进行的。

对于超过1048576ms的定时任务，放在PriorityQueue中排序，当时间低于1048576 ms时从队列中挪出来放进时间轮里。

需要实现的接口：TimeQueue.java和TimeEvent.java

[gcnyin]

[gcnyin]

接口有点奇怪啊。不应该是类似于这种吗

interface Timer {
  void runDelayed(Runnable r, long step, TimeUnit tu);
}

[wkgcass]

接口有点奇怪啊。不应该是类似于这种吗

interface Timer {
  void runDelayed(Runnable r, long step, TimeUnit tu);
}

不应该

[gcnyin]

[gcnyin]

@wkgcass 说

这个接口设计是有原因的。因为selector要根据最近定时任务的时间poll，还要根据是否有定时任务来决定是否永久等待。而且定时任务还可以随时取消。

[wkgcass]

这个接口设计是有原因的。因为selector要根据最近定时任务的时间poll，还要根据是否有定时任务来决定是否永久等待。而且定时任务还可以随时取消。
这里除了TimeElem的get方法是个util之外其他都是有实际作用的。

[gcnyin]

vproxy/base/src/main/java/vproxybase/util/time/impl/TimeQueueImpl.java

Line 9 in 74ef345

PriorityQueue<TimeElemImpl<T>> queue = new PriorityQueue<>((a, b) -> (int) (a.triggerTime - b.triggerTime));

@wkgcass 这块写的有点问题，如果差大于Integer.MAX_VALUE 2147483647就溢出了。建议改成

 PriorityQueue<TimeElemImpl<T>> queue = new PriorityQueue<>(Comparator.comparingLong(elem -> elem.triggerTime)); 

[gcnyin]

我在我的branch里改吧