Timer
本次会主要讨论大家使用较多的方案，首先第一个就是 Timer 定时器，它可以在指定时间后运行或周期性运行任务；使用方法也非常简单：
这样便可创建两个简单的定时任务，分别在 3s/5s 之后运行。
使用起来确实很简单，但也有不少毛病，想要搞清楚它所存在的问题首先就要理解其实现原理。
实现原理
定时任务要想做到按照我们给定的时间进行调度，那就得需要一个可以排序的容器来存放这些任务。
在 Timer 中内置了一个 TaskQueue 队列，用于存放所有的定时任务。
其实本质上是用数组来实现的一个最小堆，它可以让每次写入的定时任务都按照执行时间进行排序，保证在堆顶的任务执行时间是最小的。
这样在需要执行任务时，每次只需要取出堆顶的任务运行即可，所以它取出任务的效率很高为
。
结合代码会比较容易理解：
在写入任务的时候会将一些基本属性存放起来（任务的调度时间、周期、初始化任务状态等），最后就是要将任务写入这个内置队列中。
在任务写入过程中最核心的方法便是这个 fixUp() ,它会将写入的任务从队列的中部通过执行时间与前一个任务做比对，一直不断的向前比较。
如果这个时间是最早执行的，那最后将会被移动到堆顶。
通过这个过程可以看出 Timer 新增一个任务的时间复杂度为
。
再来看看它执行任务的过程，其实在初始化 Timer 的时候它就会在后台启动一个线程用于从 TaskQueue 队列中获取任务进行调度。
所以我们只需要看他的 run() 即可。
从这段代码中很明显可以看出这个线程是一直不断的在调用
task = queue.getMin();
来获取任务，最后使用 task.run() 来执行任务。
从 getMin() 方法中可以看出和我们之前说的一致，每次都是取出堆顶的任务执行。
一旦取出来的任务执行时间满足要求便可运行，同时需要将它从这个最小堆实现的队列中删除；也就是调用的 queue.removeMin() 方法。
其实它的核心原理和写入任务类似，只不过是把堆尾的任务提到堆顶，然后再依次比较将任务往后移，直到到达合适的位置。
从刚才的写入和删除任务的过程中其实也能看出，这个最小堆只是相对有序并不是绝对的有序。
源码看完了，自然也能得出它所存在的问题了。
- 后台调度任务的线程只有一个，所以导致任务是阻塞运行的，一旦其中一个任务执行周期过长将会影响到其他任务。
Timer本身没有捕获其他异常（只捕获了InterruptedException），一旦任务出现异常（比如空指针）将导致后续任务不会被执行。
