hi, moe This is the main differences:
ScheduledThreadPoolExecutor O(log N) for adding new task O(1) per each timer tick (but tick per each task, so N overall) O(log N) cancelling the task lock per each tick/task HashedWheelTimer O(1) adding new task O(m) per each timer tick (m ~ N/C where C > 512 approx), so ~C ticks overall O(m) for cancelling a task lock per bucket of tasks (on each tick) best regards, Jason > On Jan 24, 2019, at 10:09, 徐靖峰 <[email protected]> wrote: > > 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 >
