Introduction

Timer.schedule() and Timer.scheduleAtFixedRate() both run periodic TimerTask work, but they use different timing rules. The practical distinction is fixed-delay versus fixed-rate scheduling. If you understand that difference, you can predict whether executions drift, bunch up, or try to catch up after delays.

Fixed Delay with schedule

schedule(task, delay, period) uses fixed-delay behavior. Each next execution is effectively based on when the previous execution finished.

1import java.util.Timer;
2import java.util.TimerTask;
3
4Timer timer = new Timer();
5timer.schedule(new TimerTask() {
6    @Override
7    public void run() {
8        System.out.println("schedule tick: " + System.currentTimeMillis());
9    }
10}, 1000, 2000);

If the task runs long, the next execution shifts later. This causes drift over time, but it avoids the scheduler trying to “catch up” aggressively.

That makes fixed delay a reasonable choice when spacing between runs matters more than strict clock alignment.

Fixed Rate with scheduleAtFixedRate

scheduleAtFixedRate(task, delay, period) aims to maintain a regular rate relative to the original schedule.

1import java.util.Timer;
2import java.util.TimerTask;
3
4Timer timer = new Timer();
5timer.scheduleAtFixedRate(new TimerTask() {
6    @Override
7    public void run() {
8        System.out.println("fixed-rate tick: " + System.currentTimeMillis());
9    }
10}, 1000, 2000);

If one execution is delayed, the scheduler may run later executions closer together to realign with the intended schedule.

That is why fixed rate is better when you care about wall-clock regularity, such as every second or every minute, rather than just waiting a fixed gap after completion.

Think in Terms of Drift vs Catch-Up

A useful mental model is:

• 'schedule: wait period after the previous run completes'
• 'scheduleAtFixedRate: try to hit each planned time slot on the calendar'

So if a task that should run every 2 seconds accidentally takes 3 seconds:

• fixed delay drifts later and later
• fixed rate may fire the next run immediately or with a shorter gap to catch up

This difference matters most when tasks sometimes take a nontrivial amount of time.

Example with a Slow Task

A small demo makes the behavior clearer.

1import java.util.Timer;
2import java.util.TimerTask;
3
4Timer timer = new Timer();
5timer.scheduleAtFixedRate(new TimerTask() {
6    @Override
7    public void run() {
8        long start = System.currentTimeMillis();
9        System.out.println("start: " + start);
10        try {
11            Thread.sleep(3000);
12        } catch (InterruptedException e) {
13            Thread.currentThread().interrupt();
14        }
15        System.out.println("end: " + System.currentTimeMillis());
16    }
17}, 1000, 2000);

Because the task takes longer than the period, fixed-rate scheduling tries to maintain the nominal timetable. In practice, that can lead to immediate follow-up executions once the thread becomes free.

With schedule, the next execution would simply be delayed relative to the completion time instead.

Android-Specific Caveat

On Android, Timer is available because it comes from Java, but it is often not the best scheduling tool for application architecture.

Important points:

• 'TimerTask runs on a background thread, not the main UI thread'
• UI updates must be posted back to the main thread
• long-lived periodic work often fits better in WorkManager, coroutines, or Handler-based scheduling depending on the use case

A quick UI-safe pattern:

new android.os.Handler(android.os.Looper.getMainLooper()).post(() -> {
    // update UI here
});

If the scheduled task needs to touch views directly, this matters immediately.

When to Use Each Method

Use schedule when:

• you want a stable delay after task completion
• slight drift is acceptable or desirable
• you do not want catch-up behavior

Use scheduleAtFixedRate when:

• you want executions aligned to a regular schedule
• you care about nominal frequency more than completion spacing
• catch-up behavior is acceptable

This is a semantics choice, not just an API naming detail.

Common Pitfalls

The most common mistake is treating the two methods as interchangeable even though they use different timing models. Another is updating Android UI objects directly from a TimerTask, which runs off the main thread. Developers also often schedule work whose execution time is longer than the configured period and then get surprising bunching behavior from scheduleAtFixedRate. A final issue is using Timer for lifecycle-sensitive Android work where a platform-specific scheduling tool would be more robust.

Summary

• 'schedule uses fixed-delay semantics and tends to drift when tasks run long.'
• 'scheduleAtFixedRate uses fixed-rate semantics and may try to catch up after delays.'
• The right choice depends on whether you care more about completion spacing or clock regularity.
• 'TimerTask runs on a background thread, so Android UI updates must be posted to the main thread.'
• For many Android workloads, higher-level scheduling tools are better than Timer.