由扫描定时器说开去

   书上得来总觉浅，绝知此事要躬行。以前觉得对于自己维护的模块的扫描定时器很有把握的，但是，最近一次和同事的讨论后，才发现和了解真正扫描定时器的运行时行为，真是实践出真知啊！

  

    讨论应用场景是如此的：同事想解决扫描定时器下挂载过多的定时任务时，定时器任务被延迟或者延后。同事就觉得原有的扫描定时器模块可能不能应付新的局面；然后，他就通过两级的扫描定时器去实现。

 

   这样的设计使得扫描定时器的第一级显得特别瘦弱，而第二级的扫描定时器其实做的很多事情就是原来第一级扫描定时器应该干的事情。当时看了实现代码后，我觉得这种设计可能有点达不到他初始所设想的目的，然后就和他一起讨论。

  

  最后通过讨论，我们两个人首先达成一定的共识：为了避免同种类型的扫描定时器下挂载定时器任务过多，可以针对每一种定时器任务类型建立一个扫描定时器，分而治之，但这样会带来实现上的复杂性。不过想想它所能带来的优势，觉得也是值得努力的。

 

   后来考虑到我们一位女同事维护的模块也有类似应用场景，我俩就建议她也采取这样的设计方法。但她说在我们系统原来的扫描定时器设计中，根本没有考虑这种问题，而且原来系统中也会发生的很多业务制造定时器任务，造成扫描定时器中挂载很多定时器任务，但是，也没有见到定时器所遇到性能问题。

 

   这句话点中了要害，也揭示了扫描定时器的生前身后名。是啊，以前的业务就存在此种问题，但也确实不存在这种性能问题的。

 

   思考良久。。。。，觉得对扫描定时器原来的设计和自身的特点其实能够规避定时器过多所造成的影响。例如，如果在我们的业务中虽然启动的定时器任务比较多，但是很多是幻起幻灭的，占用时间很少，其不会在很长时间内影响扫描定时器本身的任务队列长度，使得扫描定时器任务队列总能保持在一个合适的量级，那么扫描定时器所挂载的定时器任务就不会有太多的延迟或漂移。

  

   现在总结下扫描定时器的特点，扫描定时器是一个充满短时间的定时器任务或在少数量级规模上的长时间定时器任务，这样扫描定时器+线程池的机制是高效的。但如果扫描定时器内的存在大量定时器任务都是长时间存在的任务，再加上可能的临时性的定时任务，则扫描定时器的性能会有所下降，这就是现在对扫描定时器的认识。