很多时候，我们需要定时任务实现一些诸如刷新，心跳，保活等功能。这些定时任务往往逻辑很简单，使用定时任务的框架(例如springboot @Scheduled)往往大材小用。
下面是一个定时任务的典型写法，每隔30s发送心跳
public static void main(String[] args) {
Thread t = new Thread(() -> {
while (true) {
try {
//发送心跳的业务代码
heartbeat();
Thread.sleep(1000L * 30);
} catch (Exception e) {
//print the error log
e.printStackTrace();
}
}
});
t.start();
}
如果你使用了IDEA或者其他的Java集成开发环境，你会发现编辑器会提示你Call to 'Thread.sleep()' in a loop, probably busy-waiting 点开提示信息，发现这样的写法有可能会导致忙等待和死锁
忙等待 busy-waiting占用大量cpu资源，cpu利用率会达到99%,可能会完全吃掉一核cpu资源，导致其他业务甚至是宿主机的异常。
你可能会说，这样的写法怎么会导致忙等待 busy-waiting呢，我明明已经sleep()了呀，心跳任务每隔30s才执行一次啊。
如果heartbeat()抛出了异常（空指针，代码错误，网络错误等），sleep()语句就会跳过，进入了异常分支，休眠30s的目的无法达到，程序就会进入死循环，以疯狂的速度执行heartbeat()语句。更有甚者，如果你捕获异常并打印日志，日志甚至能很快写满整个硬盘。
当然，你也可以将sleep语句提到前面来，先执行Thread.sleep()，这样，可以规避忙等待风险。但是还有另外一个坑在等待着你。点开Thread.sleep()文档
Causes the currently executing thread to sleep (temporarily cease execution) for the specified number of milliseconds, subject to the precision and accuracy of system timers and schedulers. The thread does not lose ownership of any monitors.
重点在这一句The thread does not lose ownership of any monitors. monitor就是Java的重量级锁，平时我们使用的synchronized关键字就是基于monitor实现的。也就是说，线程在sleep的过程中并不会释放所持有的锁，这会导致严重的并发问题，甚至是死锁。你可能又会说，我写的代码里没有锁没有synchronized关键字，我能不能放心使用呢？
答案是不能，你的代码里没锁，不代表你依赖的代码里没锁，不代表后续的维护者不会加锁。这是一个技术债务，在绝大多数的情况下都不会出问题，但也许有一天会暴雷。
作为一个负责人的开发者，作为一个有着代码洁癖的人，作为一个无法忍受IDEA黄色提示的人，作为一个简洁至上的人，作为一个不想滥用框架的人，我推荐使用jdk自带的java.util.Timer代码如下
public static void main(String[] args) {
Timer timer = new Timer();
timer.schedule(new TimerTask() {
@Override
public void run() {
try {
//发送心跳的业务代码
heartbeat();
} catch (Exception e) {
//print the error log
e.printStackTrace();
}
}
}, 1000L * 30, 1000L * 30);
}
同样实现的是30s间隔执行心跳操作，使用Timer不会有上述我们说的忙等待和死锁的风险。Timer内部使用了一个线程，和我们单独new Thread()的效果是一样的。值得一提的是，Timer是基于wait(),notify()机制实现的，与sleep()相比，wait()会释放锁(也就是monitor)。