Sleeping Threads in Java

Using sleep correctly

import java.util.concurrent.TimeUnit;
import java.util.concurrent.atomic.AtomicBoolean;

class Worker implements Runnable {
    private final AtomicBoolean running = new AtomicBoolean(true);

    public void stop() { running.set(false); }

    @Override public void run() {
        while (running.get()) {
            // 1) Do periodic work
            doWork();

            // 2) Delay ~1 second (not real-time precise)
            try {
                TimeUnit.SECONDS.sleep(1);
            } catch (InterruptedException ie) {
                // Best practice: restore interrupt status, then exit or propagate
                Thread.currentThread().interrupt();
                break;
            }
        }
    }

    private void doWork() {
        // ... your task ...
    }
}

Key points:

• Don’t swallow interrupts: Either re-interrupt (as above) or propagate the exception so higher layers can decide.
• Not a timer: The actual delay can be longer due to OS scheduling/timer granularity. For precise or repeated tasks, use a scheduler.
• Locks: sleep does not release any monitors you hold; avoid sleeping inside synchronized sections.
• Virtual threads (Java 21+): Sleeping parks the virtual thread efficiently, but the same correctness rules apply.

Modern alternative: schedule at a fixed rate

Prefer a scheduler for periodic work such as UI refresh, polling, or maintenance tasks.

import java.util.concurrent.*;

public class SchedulerDemo {
    public static void main(String[] args) throws InterruptedException {
        ScheduledExecutorService ses = Executors.newSingleThreadScheduledExecutor();

        ScheduledFuture<?> handle = ses.scheduleAtFixedRate(
            () -> updateFrame(), 0, 1, TimeUnit.SECONDS);

        // Let it run for 10 seconds, then stop
        TimeUnit.SECONDS.sleep(10);
        handle.cancel(true);   // may interrupt the running task
        ses.shutdown();
    }

    static void updateFrame() {
        // periodic task body
    }
}

Why this is better than sleep in a loop: The scheduler compensates for drift (with scheduleAtFixedRate), handles cancellation, and centralizes thread management.

Common pitfalls

• Ignoring InterruptedException or logging it without action.
• Assuming sleep(1000) is exactly 1,000 ms of delay under all loads.
• Using sleep as a synchronization mechanism between threads.
• Sleeping while holding locks, increasing contention.

Self-check

1. What should you do when a sleeping thread is interrupted?
2. When would you choose ScheduledExecutorService over Thread.sleep?
3. Does Thread.sleep release any monitors held by the thread?

Exercise: Modify Slide Show