Timer和TimerTask通过单线程调度定时任务，适合轻量级、短时任务，但异常或长任务会阻塞或终止整个调度；应优先使用ScheduledThreadPoolExecutor，因其支持多线程、异常隔离和更灵活的调度，提升系统健壮性。
在Java中，
Timer和
TimerTask这对组合，就像是程序世界里的一对老搭档，专门负责那些需要“定时”或“周期性”执行的任务。它们的核心价值在于提供了一个轻量级的任务调度机制，让你能轻松地安排一段代码在未来的某个时间点运行，或者每隔一段时间就重复执行。但别看它们用起来简单，如果不注意一些细节，踩坑也是常有的事。理解它们的局限性、异常处理方式以及与现代并发工具的对比，是写出健壮定时任务的关键。
解决方案
使用
Timer和
TimerTask来调度任务，其基本模式是创建一个
Timer实例，然后定义一个继承自
TimerTask的类，重写其
run()方法来包含你的业务逻辑。最后，通过
Timer的
schedule()或
scheduleAtFixedRate()方法将任务提交。
一个简单的例子，如果你想让某个操作每隔5秒执行一次，可以这么做：
import java.util.Timer;
import java.util.TimerTask;
public class MyScheduledTask extends TimerTask {
private int counter = 0;
@Override
public void run() {
System.out.println("任务执行了！当前计数: " + (++counter) + " - 线程: " + Thread.currentThread().getName());
// 模拟一些可能出错的逻辑
if (counter == 3) {
System.out.println("模拟一个运行时异常发生...");
throw new RuntimeException("任务在第三次执行时失败了！");
}
}
public static void main(String[] args) {
Timer timer = new Timer("MyCustomTimerThread", true); // 设置为守护线程
MyScheduledTask task = new MyScheduledTask();
// 延迟1秒后开始，每5秒执行一次
timer.scheduleAtFixedRate(task, 1000, 5000);
System.out.println("定时器已启动，等待任务执行...");
// 模拟主线程做其他事情，或者等待一段时间后关闭timer
try {
Thread.sleep(20000); // 让任务执行几次
} catch (InterruptedException e) {
Thread.currentThread().interrupt();
}
timer.cancel(); // 停止所有未执行的任务并终止Timer线程
System.out.println("定时器已取消。");
}
}这里需要注意几点：
Timer通常会创建一个后台线程来执行任务。如果
Timer设置为守护线程（
true），那么当所有非守护线程都退出时，
Timer线程也会随之退出。
scheduleAtFixedRate会尝试以固定的频率执行任务，即使前一个任务执行时间过长，后续任务也会尽量追赶。而
schedule则是在前一个任务完成后，再等待设定的周期后才开始下一个任务。选择哪个取决于你的需求，我个人经验是
scheduleAtFixedRate在需要严格周期性时用得多，但要小心任务执行时间超出周期的情况。
立即学习“Java免费学习笔记（深入）”；
Timer与TimerTask的核心机制与适用场景
Timer的内部实现其实并不复杂，它维护了一个
TaskQueue来存储待执行的
TimerTask，并通过一个后台线程（通常叫
Timer-n）来轮询这个队列，到了时间点就执行任务。这个机制决定了它的一些特性和局限性。
我发现很多初学者，包括我自己当年，都容易忽略一个关键点：
Timer内部只有一个线程来执行所有
TimerTask。这意味着如果你的一个
TimerTask执行时间过长，或者在
run()方法中抛出了未捕获的异常，那么它会直接影响到其他所有等待执行的任务。长时间运行的任务会阻塞后续任务的执行，导致它们延迟；而一个未处理的运行时异常，则会直接终止
Timer的内部线程，进而导致整个
Timer实例失效，所有后续任务都不会再被执行。这在生产环境中是相当危险的，因为你可能在不知不觉中就失去了关键的定时服务。
所以，
Timer和
TimerTask更适合那些：
- 任务逻辑简单、执行时间短：比如每隔几秒刷新一个缓存状态、发送一个心跳包等。
- 对任务执行的精确性要求不高：如果任务偶尔延迟一两秒无关紧要。
- 任务之间没有强依赖关系：一个任务失败或阻塞不应该影响其他任务的正常运行。
-
异常处理能够被严格控制在
run()
方法内部：确保不会有未捕获的异常抛出。
如果你面对的是复杂的、耗时的、或者需要高并发处理的定时任务，那
Timer就显得力不从心了。它就像一个单核CPU，虽然能处理任务，但效率和容错性都有限。
深入理解TimerTask的异常处理与生命周期
关于
TimerTask的异常处理，这绝对是个重灾区。我在实际项目中就遇到过因为一个
TimerTask内部的数据库连接异常，导致整个定时器停止工作，结果是某个关键数据同步服务悄无声息地挂掉了，直到业务方投诉才发现。
当
TimerTask的
run()方法中抛出任何
RuntimeException（或其子类，如
NullPointerException、
ArrayIndexOutOfBoundsException等）并且没有被捕获时，
Timer的后台线程会因为这个异常而终止。一旦
Timer线程终止，它就无法再调度和执行任何新的任务了，即使你之前已经安排了许多任务。这个行为是静默的，你可能不会立即察觉到。
为了避免这种情况，务必在TimerTask
的run()
方法内部对所有可能抛出异常的代码块进行try-catch
处理。捕获异常后，你可以选择记录日志、发送告警、或者根据业务逻辑进行重试。
class RobustTimerTask extends TimerTask {
@Override
public void run() {
try {
// 你的业务逻辑代码
System.out.println("执行任务中...");
// 模拟一个可能失败的操作
if (System.currentTimeMillis() % 2 == 0) {
throw new IOException("模拟文件写入失败");
}
} catch (IOException e) {
System.err.println("任务执行异常: " + e.getMessage());
// 这里可以进行日志记录、报警通知等
} catch (Exception e) { // 捕获其他所有可能的运行时异常
System.err.println("捕获到未预期的异常: " + e.getMessage());
// 同样进行日志记录和报警
}
}
}至于生命周期，
TimerTask实例在被
schedule后，就进入了待执行状态。一旦执行完毕，或者
Timer被
cancel()，或者
Timer线程因异常终止，
TimerTask的生命周期也就基本结束了。
Timer的
cancel()方法会停止所有尚未执行的任务，并终止其后台线程。但要注意，如果任务正在执行中，
cancel()并不会立即中断当前正在运行的任务，它只会阻止未来任务的调度。所以，如果你有需要立即停止的长时间运行任务，
Timer的
cancel()可能无法满足你的需求，你可能需要在
TimerTask内部增加一个中断检查机制。
替代方案：ScheduledThreadPoolExecutor的优势与实践
考虑到
Timer的单线程模型和脆弱的异常处理机制，在多数企业级应用中，我们更倾向于使用
java.util.concurrent.ScheduledThreadPoolExecutor。它属于Java并发包（J.U.C）的一部分，提供了更强大、更灵活、更健壮的定时任务调度能力。
ScheduledThreadPoolExecutor的核心优势在于：
- 多线程执行：你可以配置一个线程池来执行定时任务，这意味着多个任务可以并行执行，互不阻塞。即使一个任务耗时较长，也不会影响其他任务的及时执行。
-
更健壮的异常处理：即使某个任务抛出未捕获的异常，也只会影响该任务自身，而不会导致整个调度器停止工作。
ScheduledThreadPoolExecutor
会捕获并记录这些异常，然后继续执行其他任务。 -
更灵活的调度方式：除了固定的延迟和周期执行，它还支持
Runnable
和Callable
任务，可以返回执行结果，并提供了Future
接口来管理任务的生命周期（如取消任务、获取结果）。 - 资源管理：通过线程池，可以更好地管理系统资源，避免创建过多的线程。
下面是一个使用
ScheduledThreadPoolExecutor实现相同定时任务的例子：
import java.io.IOException;
import java.util.concurrent.Executors;
import java.util.concurrent.ScheduledExecutorService;
import java.util.concurrent.ScheduledFuture;
import java.util.concurrent.TimeUnit;
public class MyScheduledExecutorTask {
private static int counter = 0;
public static void main(String[] args) {
// 创建一个包含1个线程的调度线程池
ScheduledExecutorService scheduler = Executors.newScheduledThreadPool(1);
Runnable task = () -> {
try {
System.out.println("任务执行了！当前计数: " + (++counter) + " - 线程: " + Thread.currentThread().getName());
// 模拟一些可能出错的逻辑
if (counter == 3) {
System.out.println("模拟一个运行时异常发生...");
throw new IOException("任务在第三次执行时失败了！"); // 抛出异常
}
} catch (IOException e) {
System.err.println("ScheduledExecutorService 任务执行异常: " + e.getMessage());
// 异常会被捕获并打印，但调度器不会停止
} catch (Exception e) {
System.err.println("ScheduledExecutorService 捕获到未预期的异常: " + e.getMessage());
}
};
// 延迟1秒后开始，每5秒执行一次
ScheduledFuture<?> future = scheduler.scheduleAtFixedRate(task, 1, 5, TimeUnit.SECONDS);
System.out.println("调度器已启动，等待任务执行...");
try {
Thread.sleep(20000); // 让任务执行几次
} catch (InterruptedException e) {
Thread.currentThread().interrupt();
}
future.cancel(false); // 尝试取消任务，false表示不中断正在运行的任务
scheduler.shutdown(); // 关闭调度器，等待所有任务完成
System.out.println("调度器已关闭。");
}
}对比一下，你会发现
ScheduledThreadPoolExecutor的API设计更符合现代Java并发编程的理念。它把任务提交和线程管理分离开来，提供了更细粒度的控制。在多数情况下，我都会推荐使用
ScheduledThreadPoolExecutor，因为它能让你少操心很多并发和异常处理的问题，让你的定时任务更加稳定可靠。当然，如果你的应用真的非常简单，对性能和容错性要求不高，
Timer也并非一无是处，但你需要清楚它的局限性并做好防御性编程。
