hi，all 回复一下关于引入timer的问题。关于第一个问题，是为了解决defaultFuture的timeout问题，其实这个问题在issue[1]里说的很清楚了，就是为了解决无效的遍历。 对比老的实现即可发现，老的遍历做了非常多的无用功，而timer可以更精确的控制超时。
关于netty为什么不使用的问题，我这里提交了一个issue[2]。 所有的其他讨论我认为应该在netty回复我们以后。 在使用场景上，dubbo确实有需求，在多级时间轮上，这个在引入的时候我也做过调查，并不是必须的，只要我们控制好timer的大小即可。 关于timer的逻辑耦合在抽象类，我其实没弄懂你的意思，timer当然可重用，你是想说timertask能否重用的问题么？timertask的抽象我们也可以通用（目前这里是有抽象空间的），另外timertask作为执行单元，task执行的效果不一样，当然不存在能否重用的问题，这个感觉就是schedulethreadpool执行的每个runnable都基本不太能复用是一个道理。 [1] https://github.com/apache/incubator-dubbo/issues/1371 [2] https://github.com/netty/netty/issues/8774 徐靖峰 <[email protected]> 于2019年1月24日周四 上午10:09写道： > Hi, Jason，a nice opinion. > > I have noticed that this issue[1] in Github encourage the change from > Schedule to HashedWheelTimer, but didn’t give a vert detailed reason. > > Is HashedWheelTimer really an unquestionable choice? > > [1] https://github.com/apache/incubator-dubbo/issues/1371 < > https://github.com/apache/incubator-dubbo/issues/1371> > > > 在 2019年1月24日，上午9:53，Jason Joo <[email protected]> 写道： > > > > Maybe because the main scenario dubbo faces is persistent connection. > > For persistent connections the most frequent thing is ticking. > > > > ScheduledThreadPoolExecutor is O(1)*connections compared to O(C) in > HashedWheelTimer when ticking. > > Considering connections is far less then C ScheduledThreadPoolExecutor > maybe more efficient in my opinion. > > > > best regards, > > > > Jason > >
