☕ Java

Java Single Thread — Lifecycle, States, Methods & Best Practices

Everything you need to know about Java Threading fundamentals — the main thread, creating threads via Thread class and Runnable, all six thread states, sleep, join, interrupt, daemon threads, thread priority, single-thread execution patterns, and a preview of Java 21 virtual threads.

📅

Last Updated

March 2026

⏱️

Read Time

22 min

🎯

Level

Intermediate

🏷️

Chapter

28 of 35

What is a Thread in Java?

A thread is the smallest unit of execution within a Java program. Think of a program as a factory — the factory itself is the process (with shared resources like memory, open files, and network connections), and the workers inside are the threads. Each worker (thread) follows its own sequence of instructions, but all share the factory's resources.

Every Java program starts with exactly one thread — the main thread — which executes the main() method from top to bottom. This is single-threaded execution: one instruction at a time, one after another, in strict order. Understanding single-threaded execution deeply is the essential foundation before tackling multithreading — because every concurrency bug is rooted in violating the mental model you build here.

Each thread in Java has its own call stack (for method calls and local variables), its own program counter (tracking which instruction to execute next), and its own thread-local storage. What threads share is the heap memory (objects) and static fields. This sharing is what enables threads to cooperate — and also what makes multithreading complex.

The Main Thread — Where Every Java Program Begins

When the JVM starts and calls main(String[] args), it does so on a thread it creates automatically — the main thread. This thread is a regular, non-daemon user thread. It is the parent of any threads you create within main(). When the main thread finishes, the JVM checks whether any non-daemon threads are still alive — if yes, it continues running; if no, it exits.

☕ JavaMainThread.java

public class MainThread {

    public static void main(String[] args) {

        // ─── Inspecting the main thread ──────────────────────────────────
        Thread mainThread = Thread.currentThread();

        System.out.println("Thread name    : " + mainThread.getName());
        // Output: Thread name    : main

        System.out.println("Thread ID      : " + mainThread.threadId());
        // Output: Thread ID      : 1

        System.out.println("Priority       : " + mainThread.getPriority());
        // Output: Priority       : 5  (NORM_PRIORITY = 5)

        System.out.println("Is Daemon      : " + mainThread.isDaemon());
        // Output: Is Daemon      : false  (main is always non-daemon)

        System.out.println("State          : " + mainThread.getState());
        // Output: State          : RUNNABLE

        System.out.println("Is Alive       : " + mainThread.isAlive());
        // Output: Is Alive       : true

        // ─── Modifying main thread properties ────────────────────────────
        mainThread.setName("TechSustainify-Main");
        System.out.println("Renamed to     : " + mainThread.getName());
        // Output: Renamed to     : TechSustainify-Main

        // ─── Main thread stack trace ──────────────────────────────────────
        System.out.println("\nStack trace:");
        for (StackTraceElement element : mainThread.getStackTrace()) {
            System.out.println("  at " + element);
        }
        // Shows the call stack: main() method at top
    }
}

Creating a Thread — Two Fundamental Ways

Java provides two standard ways to define the task a thread should execute. Both ultimately result in a Thread object whose start() method launches a new OS-level thread.

☕ JavaCreatingThreads.java

// ─── WAY 1: Extend Thread class ──────────────────────────────────────────
class DownloadThread extends Thread {

    private String fileUrl;
    private String destination;

    DownloadThread(String fileUrl, String destination) {
        super("Download-" + fileUrl.hashCode()); // set thread name
        this.fileUrl     = fileUrl;
        this.destination = destination;
    }

    @Override
    public void run() {
        System.out.println("[" + getName() + "] Starting download: " + fileUrl);
        // Simulate download work
        try {
            Thread.sleep(500); // simulate network delay
        } catch (InterruptedException e) {
            System.out.println("[" + getName() + "] Download interrupted!");
            Thread.currentThread().interrupt(); // restore interrupt flag
            return;
        }
        System.out.println("[" + getName() + "] Saved to: " + destination);
    }
}

// ─── WAY 2: Implement Runnable interface ─────────────────────────────────
class ReportGenerator implements Runnable {

    private String reportType;

    ReportGenerator(String reportType) {
        this.reportType = reportType;
    }

    @Override
    public void run() {
        System.out.println("[" + Thread.currentThread().getName()
                         + "] Generating " + reportType + " report...");
        try { Thread.sleep(300); } catch (InterruptedException e) {
            Thread.currentThread().interrupt();
        }
        System.out.println("[" + Thread.currentThread().getName()
                         + "] " + reportType + " report complete.");
    }
}

public class CreatingThreads {
    public static void main(String[] args) throws InterruptedException {

        // Way 1 — extend Thread
        DownloadThread dl = new DownloadThread("https://example.com/file.zip", "/tmp");
        dl.start(); // ✅ launches new thread — run() on new thread
        // dl.run(); // ❌ WRONG — runs on main thread, no new thread!

        // Way 2 — implement Runnable, wrap in Thread
        Runnable task    = new ReportGenerator("Sales");
        Thread   worker  = new Thread(task, "Report-Worker");
        worker.start();

        // Way 2b — Lambda (Runnable is a functional interface)
        Thread lambdaThread = new Thread(() -> {
            System.out.println("[" + Thread.currentThread().getName()
                             + "] Lambda task running!");
        }, "Lambda-Thread");
        lambdaThread.start();

        // Main thread continues while others run
        System.out.println("[main] All threads launched — main continues...");

        // Wait for all to finish before main exits
        dl.join();
        worker.join();
        lambdaThread.join();

        System.out.println("[main] All threads completed.");
    }
}

Thread Class vs Runnable Interface — Which to Choose?

Both approaches create threads, but they differ fundamentally in design philosophy. The Runnable approach is almost always preferred in professional Java code — and understanding why is as important as knowing the syntax.

Aspect	Extend Thread	Implement Runnable
Inheritance	Consumes the single inheritance slot — cannot extend another class	Free to extend any class — Runnable is just an interface
Separation of concerns	Task logic mixed with threading mechanism (Thread class)	Task logic (Runnable) cleanly separated from thread management
Reusability	Task tightly coupled to Thread — cannot reuse without Thread	Runnable can be submitted to thread pools, Executors, lambdas
Lambda support	No — cannot replace Thread subclass with lambda	Yes — Runnable is a functional interface: () -> { task }
Testing	Harder — must instantiate a Thread to test run() logic	Easy — test the Runnable independently without creating a Thread
Thread pool usage	Not directly compatible with ExecutorService	Submit Runnable directly to ExecutorService.execute(task)
When to choose	When you need to override Thread behaviour (rare)	Always — for every regular task that a thread should execute

☕ JavaThreadVsRunnable.java

import java.util.concurrent.ExecutorService;
import java.util.concurrent.Executors;

public class ThreadVsRunnable {

    // ❌ Thread subclass — task logic coupled to Thread
    static class EmailSenderThread extends Thread {
        private String to;
        EmailSenderThread(String to) { this.to = to; }
        @Override
        public void run() {
            System.out.println("Sending email to: " + to);
        }
        // Cannot extend EmailService or any other class!
    }

    // ✅ Runnable — task logic independent, reusable
    static class EmailSenderTask implements Runnable {
        private String to;
        EmailSenderTask(String to) { this.to = to; }
        @Override
        public void run() {
            System.out.println("Sending email to: " + to);
        }
        // Can extend EmailValidator, AuditableService, etc.!
    }

    public static void main(String[] args) throws InterruptedException {

        // Thread subclass — only works wrapped in Thread
        new EmailSenderThread("alice@example.com").start();

        // Runnable — works in THREE ways:
        Runnable task = new EmailSenderTask("bob@example.com");

        // 1. Wrapped in Thread
        new Thread(task).start();

        // 2. Submitted to thread pool (preferred in production)
        ExecutorService pool = Executors.newFixedThreadPool(2);
        pool.execute(task);
        pool.execute(new EmailSenderTask("carol@example.com"));
        pool.shutdown();

        // 3. As lambda (most concise)
        new Thread(() -> System.out.println("Lambda email!")).start();
    }
}

Thread Lifecycle — Six States

A Java thread moves through a well-defined set of states during its lifetime, defined in the Thread.State enum. Understanding these states is critical for diagnosing thread issues — thread dumps, deadlocks, and performance problems all require you to know what state each thread is in and why.

🆕

1. NEW

Thread object has been created with 'new Thread(...)' but start() has not been called yet. The thread exists as a Java object but has no corresponding OS thread. It cannot execute any code in this state. Transition: NEW → RUNNABLE when start() is called.

▶️

2. RUNNABLE

The thread has been started. From the JVM's perspective, it is 'runnable' — either actively running on a CPU core, or ready to run and waiting for the thread scheduler to assign it CPU time. Java does NOT distinguish between 'running' and 'ready' — both are RUNNABLE in Thread.State. The OS scheduler decides which RUNNABLE thread gets the CPU.

🔒

3. BLOCKED

The thread is waiting to acquire a monitor lock (synchronized block/method) that is currently held by another thread. Once the lock becomes available and the thread acquires it, it returns to RUNNABLE. BLOCKED is exclusively about synchronized monitor locks — other waiting mechanisms put a thread in WAITING or TIMED_WAITING.

⏳

4. WAITING

The thread is waiting indefinitely for another thread to perform a specific action. Causes: Object.wait() — waiting for notify()/notifyAll(). Thread.join() with no timeout — waiting for target thread to finish. LockSupport.park() — low-level parking. The thread stays WAITING until explicitly woken up. Cannot be timed out.

⏰

5. TIMED_WAITING

The thread is waiting, but with a timeout — it will automatically return to RUNNABLE when the timeout expires. Causes: Thread.sleep(ms), Object.wait(ms), Thread.join(ms), LockSupport.parkNanos(). Distinguishable from WAITING because the thread will eventually wake up on its own even if not explicitly notified.

✅

6. TERMINATED

The thread has finished execution — either because run() returned normally, or because an uncaught exception propagated out of run(). A TERMINATED thread cannot be restarted. Calling start() on a TERMINATED thread throws IllegalThreadStateException. isAlive() returns false.

☕ JavaThreadStates.java

public class ThreadStates {

    public static void main(String[] args) throws InterruptedException {

        Thread worker = new Thread(() -> {
            try {
                Thread.sleep(500); // TIMED_WAITING during sleep
            } catch (InterruptedException e) {
                Thread.currentThread().interrupt();
            }
        }, "StateWatcher");

        // ─── Observe state transitions ────────────────────────────────────
        System.out.println("Before start : " + worker.getState());
        // Before start : NEW

        worker.start();
        System.out.println("After start  : " + worker.getState());
        // After start  : RUNNABLE  (or TIMED_WAITING if sleep already started)

        Thread.sleep(100); // give worker time to reach sleep
        System.out.println("During sleep : " + worker.getState());
        // During sleep : TIMED_WAITING

        worker.join(); // wait for worker to finish
        System.out.println("After finish : " + worker.getState());
        // After finish : TERMINATED

        System.out.println("Is alive     : " + worker.isAlive());
        // Is alive     : false

        // ─── Attempting to restart a terminated thread ────────────────────
        try {
            worker.start(); // ❌ IllegalThreadStateException
        } catch (IllegalThreadStateException e) {
            System.out.println("Cannot restart: " + e.getMessage());
            // Cannot restart: (message varies by JVM)
        }
    }
}

Thread.sleep() — Pausing Execution

Thread.sleep(milliseconds) causes the currently executing thread to pause for at least the specified time, moving it to the TIMED_WAITING state. During sleep, the thread releases CPU time but does not release any monitor locks it holds. Sleep is a static method — it always acts on the current thread, regardless of which Thread object you call it on.

☕ JavaThreadSleep.java

public class ThreadSleep {

    public static void main(String[] args) {

        // ─── Basic sleep ──────────────────────────────────────────────────
        System.out.println("Task started at: " + java.time.LocalTime.now());

        try {
            Thread.sleep(2000); // sleep 2 seconds — TIMED_WAITING
        } catch (InterruptedException e) {
            // ✅ ALWAYS restore the interrupt flag when catching InterruptedException
            Thread.currentThread().interrupt();
            System.out.println("Sleep interrupted!");
            return;
        }

        System.out.println("Task resumed at: " + java.time.LocalTime.now());
        // ~2 seconds gap between the two prints

        // ─── sleep() with nanoseconds (rarely needed) ────────────────────
        try {
            Thread.sleep(1000, 500000); // 1 second + 500,000 nanoseconds
        } catch (InterruptedException e) {
            Thread.currentThread().interrupt();
        }

        // ─── Rate-limiting pattern — polling with sleep ───────────────────
        int retries = 0;
        boolean success = false;
        while (retries < 3 && !success) {
            System.out.println("Attempt " + (retries + 1) + "...");
            success = tryConnect(); // simulated network call
            if (!success) {
                try {
                    long backoff = (long) Math.pow(2, retries) * 1000L;
                    System.out.println("Retrying in " + backoff + "ms...");
                    Thread.sleep(backoff); // exponential backoff
                } catch (InterruptedException e) {
                    Thread.currentThread().interrupt();
                    break;
                }
            }
            retries++;
        }
    }

    static boolean tryConnect() {
        return Math.random() > 0.6; // 40% failure rate simulation
    }
}

Thread.join() — Waiting for Another Thread to Complete

thread.join() causes the calling thread to pause and wait until the target thread terminates. This is the fundamental mechanism for coordinating sequential completion — ensuring that one thread's results are fully ready before another thread proceeds to use them. The calling thread enters the WAITING state (or TIMED_WAITING with a timeout argument).

☕ JavaThreadJoin.java

public class ThreadJoin {

    // Simulated data pipeline: fetch → process → report
    static volatile String fetchedData   = null;
    static volatile String processedData = null;

    public static void main(String[] args) throws InterruptedException {

        long start = System.currentTimeMillis();

        // ─── Thread 1: Data Fetcher ────────────────────────────────────────
        Thread fetcher = new Thread(() -> {
            System.out.println("[Fetcher] Starting data fetch...");
            try { Thread.sleep(800); } catch (InterruptedException e) {
                Thread.currentThread().interrupt(); return;
            }
            fetchedData = "RAW:user_events_2024_q1.csv";
            System.out.println("[Fetcher] Done: " + fetchedData);
        }, "DataFetcher");

        // ─── Thread 2: Data Processor (must wait for fetcher to finish) ───
        Thread processor = new Thread(() -> {
            System.out.println("[Processor] Ready — waiting for fetch...");
            try {
                fetcher.join(); // ← WAIT for fetcher to terminate
            } catch (InterruptedException e) {
                Thread.currentThread().interrupt(); return;
            }
            // Safe to use fetchedData now — fetcher is TERMINATED
            processedData = fetchedData.replace("RAW:", "PROCESSED:").toUpperCase();
            System.out.println("[Processor] Done: " + processedData);
        }, "DataProcessor");

        fetcher.start();
        processor.start();

        // Main thread waits for processor (which already waited for fetcher)
        processor.join();
        System.out.printf("[main] Pipeline complete in %dms%n",
                          System.currentTimeMillis() - start);
        System.out.println("[main] Final data: " + processedData);

        // ─── join() with timeout ──────────────────────────────────────────
        Thread slowTask = new Thread(() -> {
            try { Thread.sleep(5000); } catch (InterruptedException e) {
                Thread.currentThread().interrupt();
            }
        }, "SlowTask");
        slowTask.start();

        slowTask.join(2000); // Wait at most 2 seconds
        if (slowTask.isAlive()) {
            System.out.println("SlowTask still running after 2s — not waiting further");
            slowTask.interrupt(); // cancel it
        } else {
            System.out.println("SlowTask finished within timeout");
        }
    }
}

Thread Interruption — Cooperative Cancellation

Java threads cannot be forcefully killed from outside. The correct approach is cooperative cancellation using the interrupt mechanism. thread.interrupt() sets the thread's interrupt flag to true. The target thread is responsible for periodically checking this flag and gracefully stopping itself.

When a thread is blocked in a method like sleep(), wait(), or join(), calling interrupt() on it causes those methods to immediately throw InterruptedException and clear the interrupt flag. The thread's catch block must restore the flag with Thread.currentThread().interrupt() if it cannot handle the interruption at that level.

☕ JavaThreadInterrupt.java

public class ThreadInterrupt {

    // ─── Long-running task that checks for interruption ───────────────────
    static class DataProcessingTask implements Runnable {

        @Override
        public void run() {
            int batchNumber = 0;

            // ✅ Check interrupt flag in loop condition
            while (!Thread.currentThread().isInterrupted()) {
                batchNumber++;
                System.out.println("Processing batch " + batchNumber + "...");

                try {
                    Thread.sleep(300); // TIMED_WAITING — interruptible
                } catch (InterruptedException e) {
                    // sleep() threw because we were interrupted
                    // InterruptedException CLEARS the flag — restore it!
                    System.out.println("Interrupted during sleep — cleaning up...");
                    Thread.currentThread().interrupt(); // ← restore flag
                    break; // exit loop gracefully
                }
            }

            // Runs only if loop exits (interrupted or condition false)
            System.out.println("Task shutdown cleanly after " + batchNumber + " batches.");
        }
    }

    public static void main(String[] args) throws InterruptedException {

        Thread worker = new Thread(new DataProcessingTask(), "DataProcessor");
        worker.start();

        Thread.sleep(1200); // Let it run for ~4 batches

        System.out.println("[main] Requesting cancellation...");
        worker.interrupt(); // ← signal the thread to stop

        worker.join(); // wait for clean shutdown
        System.out.println("[main] Worker has stopped. isAlive: " + worker.isAlive());

        // ─── Checking interrupt flag manually (non-blocking task) ─────────
        Thread cpuTask = new Thread(() -> {
            long result = 0;
            for (long i = 0; i < Long.MAX_VALUE; i++) {
                if (Thread.interrupted()) { // ← checks AND clears flag
                    System.out.println("CPU task cancelled at i=" + i);
                    return;
                }
                result += i;
            }
            System.out.println("Result: " + result);
        }, "CPUTask");

        cpuTask.start();
        Thread.sleep(100);
        cpuTask.interrupt();
        cpuTask.join();
    }
}

Thread Priority — Hints to the Scheduler

Java threads have a priority — an integer from Thread.MIN_PRIORITY (1) to Thread.MAX_PRIORITY (10), with Thread.NORM_PRIORITY (5) as the default. Thread priority is a hint to the underlying OS thread scheduler about which threads should get CPU time preference when multiple threads are RUNNABLE. It is not a guarantee.

☕ JavaThreadPriority.java

public class ThreadPriority {

    static volatile long highPriorityCount = 0;
    static volatile long lowPriorityCount  = 0;
    static volatile boolean running        = true;

    public static void main(String[] args) throws InterruptedException {

        // ─── High priority thread ─────────────────────────────────────────
        Thread highPriority = new Thread(() -> {
            while (running) highPriorityCount++;
        }, "HighPriority");
        highPriority.setPriority(Thread.MAX_PRIORITY); // 10

        // ─── Low priority thread ──────────────────────────────────────────
        Thread lowPriority = new Thread(() -> {
            while (running) lowPriorityCount++;
        }, "LowPriority");
        lowPriority.setPriority(Thread.MIN_PRIORITY); // 1

        // ─── Priority must be set BEFORE start() ─────────────────────────
        highPriority.start();
        lowPriority.start();

        Thread.sleep(1000); // let them compete for 1 second
        running = false;

        highPriority.join();
        lowPriority.join();

        System.out.println("High priority count : " + highPriorityCount);
        System.out.println("Low priority count  : " + lowPriorityCount);
        System.out.printf ("High:Low ratio      : %.2f:1%n",
                           (double) highPriorityCount / lowPriorityCount);
        // Results vary by OS — priority is only a HINT, not a guarantee

        // ─── Priority constants ───────────────────────────────────────────
        System.out.println("MIN_PRIORITY  : " + Thread.MIN_PRIORITY);  // 1
        System.out.println("NORM_PRIORITY : " + Thread.NORM_PRIORITY); // 5
        System.out.println("MAX_PRIORITY  : " + Thread.MAX_PRIORITY);  // 10

        // ─── Thread group priority cap ────────────────────────────────────
        // A thread's effective priority is min(thread.getPriority(),
        //                                     threadGroup.getMaxPriority())
        System.out.println("Main group max: " +
            Thread.currentThread().getThreadGroup().getMaxPriority()); // 10
    }
}

Daemon Threads — Background Service Workers

Java divides threads into two categories: user threads (non-daemon) and daemon threads. The JVM continues running as long as any user thread is alive. When the last user thread terminates, the JVM shuts down — immediately terminating all remaining daemon threads, regardless of what they were doing. Daemon threads are designed for background services that should not prevent the application from exiting.

☕ JavaDaemonThread.java

public class DaemonThread {

    // ─── Daemon: background heartbeat monitor ─────────────────────────────
    static class HeartbeatMonitor implements Runnable {
        @Override
        public void run() {
            int beat = 0;
            while (true) { // Intentionally infinite — daemon will be killed on JVM exit
                beat++;
                System.out.println("[Heartbeat #" + beat + "] System alive at "+
                                   java.time.LocalTime.now());
                try {
                    Thread.sleep(500);
                } catch (InterruptedException e) {
                    Thread.currentThread().interrupt();
                    return; // exit if interrupted
                }
            }
        }
    }

    // ─── Daemon: background cache cleanup ─────────────────────────────────
    static class CacheEviction implements Runnable {
        @Override
        public void run() {
            while (true) {
                System.out.println("[CacheEviction] Checking for expired entries...");
                try { Thread.sleep(2000); } catch (InterruptedException e) {
                    Thread.currentThread().interrupt(); return;
                }
            }
        }
    }

    public static void main(String[] args) throws InterruptedException {

        // ─── Setup daemon threads ─────────────────────────────────────────
        Thread heartbeat = new Thread(new HeartbeatMonitor(), "Heartbeat");
        heartbeat.setDaemon(true);  // ← MUST be called BEFORE start()
        heartbeat.start();
        System.out.println("Heartbeat daemon: " + heartbeat.isDaemon()); // true

        Thread eviction = new Thread(new CacheEviction(), "CacheEviction");
        eviction.setDaemon(true);
        eviction.start();

        // ─── User thread (non-daemon) — main work ────────────────────────
        System.out.println("[main] Starting main work...");
        Thread.sleep(1500); // Simulate 1.5 seconds of real work
        System.out.println("[main] Work complete — exiting main thread");

        // When main thread exits here, JVM will kill heartbeat & eviction daemons
        // You may see 1-3 heartbeat prints, then the program exits
        // The daemons do NOT keep the JVM alive

        // ─── setDaemon() AFTER start() throws exception ──────────────────
        Thread alreadyStarted = new Thread(() -> {});
        alreadyStarted.start();
        try {
            alreadyStarted.setDaemon(true); // ❌ IllegalThreadStateException
        } catch (IllegalThreadStateException e) {
            System.out.println("Cannot set daemon after start: " + e.getMessage());
        }
    }
}

Thread Name, ID, and Metadata

Every Java thread has metadata that is invaluable for debugging, monitoring, and logging. Meaningful thread names make thread dumps (the primary tool for diagnosing hangs and deadlocks) dramatically easier to read. Always name your threads explicitly in production code.

☕ JavaThreadMetadata.java

public class ThreadMetadata {

    public static void main(String[] args) throws InterruptedException {

        // ─── Meaningful thread names — critical for thread dump readability ─
        Thread paymentWorker = new Thread(() -> {
            System.out.println("Working on: " + Thread.currentThread().getName());
            try { Thread.sleep(100); } catch (InterruptedException e) {
                Thread.currentThread().interrupt();
            }
        }, "PaymentProcessor-Worker-1"); // ← meaningful name

        Thread anonymousWorker = new Thread(() -> {
            System.out.println("Working on: " + Thread.currentThread().getName());
        }); // ← default name: Thread-N (meaningless in thread dump)

        paymentWorker.start();
        anonymousWorker.start();

        paymentWorker.join();
        anonymousWorker.join();

        // ─── Thread metadata API ──────────────────────────────────────────
        Thread current = Thread.currentThread();

        System.out.println("getName()         : " + current.getName());
        System.out.println("threadId()        : " + current.threadId());
        System.out.println("getPriority()     : " + current.getPriority());
        System.out.println("isDaemon()        : " + current.isDaemon());
        System.out.println("isAlive()         : " + current.isAlive());
        System.out.println("getState()        : " + current.getState());
        System.out.println("isInterrupted()   : " + current.isInterrupted());
        System.out.println("getThreadGroup()  : " + current.getThreadGroup().getName());

        // ─── All active threads snapshot ──────────────────────────────────
        System.out.println("\n--- All Active Threads ---");
        Thread.getAllStackTraces().keySet().forEach(t ->
            System.out.printf("  %-35s id=%-4d daemon=%-5b state=%s%n",
                              t.getName(), t.threadId(), t.isDaemon(), t.getState())
        );
    }
}

Single-Thread Execution Patterns

Not every concurrent design requires multiple threads doing things simultaneously. Several important patterns involve a single dedicated thread for a specific concern — isolating work on one thread to eliminate synchronization complexity while still keeping the main application responsive.

📋

Event Loop Pattern

A single thread continuously processes events from a queue — one at a time, in order. Used by: Node.js (inspiration), Java Swing's EDT (Event Dispatch Thread), and Android's Looper. The advantage: no synchronization needed inside event handlers because only one thread ever accesses the shared state. JavaScript's entire concurrency model is built on this single-thread event loop.

🔧

Single-Thread Executor

ExecutorService single = Executors.newSingleThreadExecutor() — creates a thread pool with exactly one thread. All submitted tasks execute sequentially on that one thread, in submission order. Use case: database write serialization, ordered log writing, sequential state machine processing. Eliminates data races without synchronization — only one thread ever touches the data.

🖥️

Main-Thread-Only Pattern

Frameworks like Android enforce that all UI updates must happen on the main (UI) thread. Background threads do work and post results back to the main thread via handlers/coroutines. This pattern gives you thread safety for UI state without locks — the single UI thread is the sole writer.

☕ JavaSingleThreadPatterns.java

import java.util.concurrent.*;

public class SingleThreadPatterns {

    // ─── Pattern: Single-Thread Executor for ordered task processing ──────
    public static void main(String[] args) throws InterruptedException {

        // All tasks run sequentially on ONE dedicated thread
        // No synchronization needed — ordering is guaranteed
        ExecutorService singleExecutor = Executors.newSingleThreadExecutor(r -> {
            Thread t = new Thread(r, "OrderProcessor-Thread");
            t.setDaemon(true);
            return t;
        });

        // Submit 5 tasks — they execute in order, one at a time
        for (int i = 1; i <= 5; i++) {
            final int orderId = i;
            singleExecutor.execute(() -> {
                System.out.println("[" + Thread.currentThread().getName()
                                 + "] Processing order #" + orderId);
                try { Thread.sleep(200); } catch (InterruptedException e) {
                    Thread.currentThread().interrupt();
                }
                System.out.println("[" + Thread.currentThread().getName()
                                 + "] Order #" + orderId + " complete");
            });
        }

        singleExecutor.shutdown();
        singleExecutor.awaitTermination(10, TimeUnit.SECONDS);
        // Output: All 5 orders processed IN ORDER on OrderProcessor-Thread

        // ─── Pattern: Event Loop simulation ──────────────────────────────
        BlockingQueue<String> eventQueue = new LinkedBlockingQueue<>();

        // Producer — adds events
        Thread producer = new Thread(() -> {
            String[] events = {"USER_LOGIN", "PAGE_VIEW", "PURCHASE", "LOGOUT", "POISON"};
            for (String event : events) {
                try {
                    Thread.sleep(100);
                    eventQueue.put(event);
                    System.out.println("[Producer] Published: " + event);
                } catch (InterruptedException e) {
                    Thread.currentThread().interrupt(); return;
                }
            }
        }, "EventProducer");

        // Event loop — single thread, processes one event at a time
        Thread eventLoop = new Thread(() -> {
            while (true) {
                try {
                    String event = eventQueue.take(); // blocks until available
                    if ("POISON".equals(event)) break; // shutdown signal
                    System.out.println("[EventLoop] Processing: " + event);
                } catch (InterruptedException e) {
                    Thread.currentThread().interrupt(); return;
                }
            }
            System.out.println("[EventLoop] Shutting down.");
        }, "EventLoop-Thread");

        producer.start();
        eventLoop.start();
        producer.join();
        eventLoop.join();
    }
}

Virtual Threads — Java 21's Game Changer (Brief Introduction)

Java 21 (LTS) introduced Virtual Threads (Project Loom, JEP 444) as a production-ready feature. Virtual threads are JVM-managed lightweight threads — not OS threads. They are cheap enough to create millions of them, making the traditional thread-per-request model viable again even for highly concurrent servers. A blocking call in a virtual thread unmounts the virtual thread from its carrier OS thread, freeing the OS thread to run other virtual threads — no OS thread is ever truly blocked.

☕ JavaVirtualThreads.java

// Java 21+ — Virtual Threads
import java.util.concurrent.Executors;

public class VirtualThreads {

    public static void main(String[] args) throws InterruptedException {

        // ─── Creating a single virtual thread ─────────────────────────────
        Thread vThread = Thread.ofVirtual()
                               .name("my-virtual-thread")
                               .start(() -> {
            System.out.println("Running on virtual thread: "
                             + Thread.currentThread().isVirtual()); // true
        });
        vThread.join();

        // ─── Platform (traditional) thread vs Virtual thread ──────────────
        Thread platform = Thread.ofPlatform().name("platform-thread").start(() -> {
            System.out.println("Platform virtual: "
                             + Thread.currentThread().isVirtual()); // false
        });
        platform.join();

        // ─── Virtual thread executor — one per task (cheap!) ──────────────
        // Traditional: Executors.newFixedThreadPool(200) — 200 OS threads
        // Virtual: Executors.newVirtualThreadPerTaskExecutor() — millions possible
        try (var executor = Executors.newVirtualThreadPerTaskExecutor()) {
            for (int i = 1; i <= 10; i++) {
                final int taskId = i;
                executor.submit(() -> {
                    System.out.println("Task " + taskId + " on virtual thread: "
                                     + Thread.currentThread().isVirtual());
                    Thread.sleep(100); // blocking — but doesn't pin OS thread!
                    return null;
                });
            }
        } // executor.close() waits for all tasks

        System.out.println("All virtual thread tasks complete.");

        // ─── Key difference: cost of creation ────────────────────────────
        // Platform thread: ~1MB stack, OS resource, expensive to create
        // Virtual thread : ~few KB initial, JVM-managed, cheap to create
        // You can create 1,000,000 virtual threads — not 1,000,000 OS threads
    }
}

Common Mistakes & Pitfalls

These mistakes are the most frequently encountered threading bugs in Java — from calling run() instead of start() to silently swallowing InterruptedException.

☕ JavaThreadMistakes.java

public class ThreadMistakes {

    // ❌ MISTAKE 1: Calling run() instead of start() — no new thread created
    static void mistake1() {
        Thread t = new Thread(() -> {
            System.out.println("Running on: " + Thread.currentThread().getName());
        }, "WorkerThread");

        t.run();   // ❌ Runs on the CALLING thread — output: 'main'
        // t.start(); // ✅ Creates new thread — output: 'WorkerThread'
    }

    // ❌ MISTAKE 2: Restarting a terminated thread
    static void mistake2() throws InterruptedException {
        Thread t = new Thread(() -> System.out.println("Done"), "OneShot");
        t.start();
        t.join();  // wait for completion
        try {
            t.start(); // ❌ IllegalThreadStateException — already terminated
        } catch (IllegalThreadStateException e) {
            System.out.println("Cannot restart: " + e); // ✅ Handle this case
        }
    }

    // ❌ MISTAKE 3: Swallowing InterruptedException — silent bug
    static void mistake3() {
        Thread t = new Thread(() -> {
            try {
                Thread.sleep(10000);
            } catch (InterruptedException e) {
                // ❌ Do nothing — interrupt signal lost forever!
                // Thread continues running even after interrupt() was called
            }
            // This still executes even after interruption — unintended!
            System.out.println("Continuing despite interrupt — bug!");
        });
        t.start();
        t.interrupt();
    }

    // ❌ MISTAKE 4: Setting daemon AFTER start()
    static void mistake4() {
        Thread t = new Thread(() -> {});
        t.start();
        try {
            t.setDaemon(true); // ❌ IllegalThreadStateException
        } catch (IllegalThreadStateException e) {
            System.out.println("Set daemon before start!");
        }
    }

    // ❌ MISTAKE 5: Thread.sleep() to synchronize — unreliable timing
    static volatile String sharedResult = null;
    static void mistake5() throws InterruptedException {
        Thread producer = new Thread(() -> {
            try { Thread.sleep(100); } catch (InterruptedException e) {
                Thread.currentThread().interrupt();}
            sharedResult = "computed";
        });
        producer.start();
        Thread.sleep(200); // ❌ Hoping 200ms is enough — fragile, race condition!
        System.out.println(sharedResult); // may still be null under load
        // ✅ Fix: producer.join() — guaranteed synchronization
    }

    public static void main(String[] args) throws InterruptedException {
        mistake1(); mistake2(); mistake3(); mistake4(); mistake5();
    }
}

Bad Practices & Anti-Patterns

These thread anti-patterns appear consistently in code reviews and lead to resource leaks, unreliable behaviour, and unmaintainable threading code.

🚫

Creating Raw Threads Instead of Using Executors

Manually creating Thread objects ('new Thread(task).start()') in production code bypasses thread lifecycle management, resource limits, and monitoring. Every uncontrolled thread is a potential resource leak. Use ExecutorService and thread pools instead — they manage thread lifecycle, handle exceptions, support Future/CompletableFuture, and allow graceful shutdown. Raw Thread creation is acceptable only for quick prototyping or when you have a very specific low-level reason.

🚫

Using Thread.sleep() for Coordination

Using sleep() to 'wait for another thread to finish' (Thread.sleep(500); // hopefully done by now) is fundamentally broken. The amount of time to sleep is always a guess — too short causes race conditions, too long wastes time. The correct tool is join() for 'wait for thread to finish', CountDownLatch for 'wait for N events', and BlockingQueue for producer-consumer. sleep() is for introducing deliberate delays (rate limiting, retry backoff) — not for synchronization.

🚫

Calling Thread.stop(), Thread.suspend(), Thread.resume()

These methods are deprecated and must never be used. Thread.stop() kills a thread abruptly, releasing all locks it holds — leaving shared data in a partially-modified, inconsistent state. Thread.suspend() stops a thread while still holding its locks — deadlock guaranteed if another thread tries to acquire those locks. Use the interrupt mechanism and cooperative cancellation (checking isInterrupted() in loops) for safe thread termination.

🚫

Extending Thread When Runnable Suffices

Extending Thread is only justified when you need to override Thread's behaviour (extremely rare). For defining what a thread does, always implement Runnable (or Callable). Extending Thread wastes your single inheritance slot, tightly couples task logic to the threading mechanism, makes the task incompatible with ExecutorService, and cannot be used with lambda expressions. Runnable wins on every axis for defining task logic.

🚫

Ignoring Thread UncaughtExceptionHandler

If run() throws an unchecked exception that propagates out, the thread terminates silently — the exception is swallowed unless an UncaughtExceptionHandler is set. In production, always configure: Thread.setDefaultUncaughtExceptionHandler((thread, ex) -> log.error('Thread ' + thread.getName() + ' died', ex)). Without this, threading failures are invisible — threads die, work is lost, and no log entry indicates the failure.

🚫

Creating Unbounded Numbers of Threads

Each platform thread consumes ~1MB of stack memory and corresponding OS resources. Spawning thousands of threads for thousands of concurrent tasks exhausts memory and degrades performance through context-switching overhead. The correct pattern: submit tasks to a bounded thread pool (Executors.newFixedThreadPool(N)) where N = number of CPU cores for CPU-bound work, or use virtual threads (Java 21) for I/O-bound work. Never do: while (true) { new Thread(task).start(); }.

Real-World Production Code Examples

The following examples demonstrate professional thread usage patterns found in real enterprise Java applications — a background job runner and an asynchronous file processor.

☕ JavaBackgroundJobRunner.java — Production Thread Patterns

package com.techsustainify.job;

import java.util.concurrent.*;
import java.util.concurrent.atomic.AtomicInteger;

/**
 * Production-grade background job runner.
 * Demonstrates: named threads, daemon config, uncaught exception handler,
 * graceful shutdown, interrupt handling, and status tracking.
 */
public class BackgroundJobRunner {

    private final ExecutorService executor;
    private final AtomicInteger   jobsCompleted = new AtomicInteger(0);
    private final AtomicInteger   jobsFailed    = new AtomicInteger(0);
    private volatile boolean      isShuttingDown = false;

    public BackgroundJobRunner(int threadCount) {
        AtomicInteger counter = new AtomicInteger(0);

        this.executor = Executors.newFixedThreadPool(threadCount, r -> {
            Thread t = new Thread(r,
                "BgJobRunner-Worker-" + counter.incrementAndGet());
            t.setDaemon(false); // user thread — keep JVM alive
            t.setPriority(Thread.NORM_PRIORITY - 1); // slightly below normal

            // ✅ Log uncaught exceptions — never lose a thread failure silently
            t.setUncaughtExceptionHandler((thread, ex) -> {
                System.err.println("[FATAL] Thread '" + thread.getName()
                                 + "' died unexpectedly: " + ex.getMessage());
                jobsFailed.incrementAndGet();
            });
            return t;
        });
    }

    public void submitJob(String jobName, Runnable task) {
        if (isShuttingDown) {
            System.out.println("Rejecting job '" + jobName + "' — shutting down");
            return;
        }
        executor.execute(() -> {
            String threadName = Thread.currentThread().getName();
            System.out.println("[" + threadName + "] Starting: " + jobName);
            long start = System.currentTimeMillis();
            try {
                task.run();
                long elapsed = System.currentTimeMillis() - start;
                System.out.printf("[%s] Completed: %s in %dms%n",
                                  threadName, jobName, elapsed);
                jobsCompleted.incrementAndGet();
            } catch (Exception e) {
                System.err.println("[" + threadName + "] Failed: " + jobName
                                 + " — " + e.getMessage());
                jobsFailed.incrementAndGet();
            }
        });
    }

    public void shutdown() throws InterruptedException {
        isShuttingDown = true;
        executor.shutdown();
        if (!executor.awaitTermination(30, TimeUnit.SECONDS)) {
            System.err.println("Force-shutting down after 30s timeout");
            executor.shutdownNow();
        }
        System.out.printf("Shutdown complete — Completed: %d, Failed: %d%n",
                          jobsCompleted.get(), jobsFailed.get());
    }

    public static void main(String[] args) throws InterruptedException {
        BackgroundJobRunner runner = new BackgroundJobRunner(3);

        runner.submitJob("SendWelcomeEmail",  () -> { Thread.sleep(200); return; });
        runner.submitJob("GenerateInvoice",   () -> { Thread.sleep(300); return; });
        runner.submitJob("SyncInventory",     () -> { Thread.sleep(150); return; });
        runner.submitJob("UpdateAnalytics",   () -> { Thread.sleep(400); return; });
        runner.submitJob("FailingJob", () -> {
            throw new RuntimeException("Database connection failed");
        });

        runner.shutdown();
        // Shutdown complete — Completed: 4, Failed: 1
    }
}

Thread Lifecycle Flowchart

This flowchart shows all six Java thread states and the transitions between them — the triggers that move a thread from one state to another.

🆕 NEWThread created, start() not called

start() called

▶️ RUNNABLERunning or ready to run on CPU

Needs synchronized lock (held by other)

🔒 BLOCKEDWaiting for synchronized monitor lock

Lock acquired

⏳ WAITINGwait() / join() / park() — indefinite

notify() / notifyAll() / unpark()

⏰ TIMED_WAITINGsleep(ms) / wait(ms) / join(ms)

Timeout expires or notify()

✅ TERMINATEDrun() completed or exception

Code Execution Flow — from source to output

Java Single Thread Interview Questions — Beginner to Advanced

These questions are consistently asked in Java mid-level and senior interviews covering threading fundamentals, Java concurrency, and system design rounds.

A thread is the smallest unit of execution within a program — a lightweight sub-process with its own stack, program counter, and local variables, but sharing the process's heap memory and static data. A process is a complete program in execution with its own isolated memory space — processes cannot directly share memory with each other (they use IPC). Key differences: (1) Threads share memory; processes do not. (2) Thread creation is cheap (100s of microseconds); process creation is expensive (10s of milliseconds). (3) A crash in one thread can potentially crash the entire process; a process crash doesn't affect other processes. (4) Communication between threads uses shared memory (needs synchronization); between processes uses IPC (pipes, sockets, shared memory segments).

start(): creates a new OS-level thread and invokes run() on that NEW thread — execution is concurrent. run(): is a regular method call — executes synchronously on the CALLING thread, no new thread is created. Critical consequence: calling thread.run() directly does the work on the current thread sequentially — it does NOT achieve concurrency, even though it executes the same code. A common beginner mistake is calling run() when start() was intended — the program appears to work but is not actually multithreaded. Calling start() on an already-started thread throws IllegalThreadStateException.

Java Thread.State enum defines six states: (1) NEW — created, start() not called. (2) RUNNABLE — running or ready to run; JVM doesn't distinguish 'currently running' from 'waiting for CPU'. (3) BLOCKED — waiting to acquire a synchronized monitor lock held by another thread. (4) WAITING — indefinitely waiting (Object.wait(), Thread.join(), LockSupport.park()) — needs explicit notification to wake up. (5) TIMED_WAITING — waiting with a timeout (Thread.sleep(ms), Object.wait(ms), Thread.join(ms)) — wakes automatically when time expires. (6) TERMINATED — run() has completed or an uncaught exception caused the thread to stop. A TERMINATED thread cannot be restarted.

Four reasons: (1) Java only supports single inheritance — extending Thread consumes the one inheritance slot. Implementing Runnable keeps the class free to extend another class. (2) Separation of concerns — Runnable defines WHAT to do; Thread manages HOW to execute it. Mixing them in one class violates SRP. (3) Reusability — a Runnable can be submitted to ExecutorService, thread pools, ForkJoinPool, ScheduledExecutorService, and wrapped in Thread. A Thread subclass is only usable as a Thread. (4) Lambda compatibility — Runnable is a functional interface; you can write () -> { task } instead of an anonymous Thread subclass. Extending Thread is only appropriate when overriding Thread's own behaviour (e.g., customizing thread local variables) — an extremely rare need.

sleep(ms): static method of Thread; pauses the CURRENT thread for the specified time; does NOT release any synchronized locks held by the thread; throws InterruptedException; belongs to Thread class. wait(): instance method of Object; can only be called inside a synchronized block; releases the monitor lock and puts the thread in WAITING state until notify()/notifyAll() is called or timeout expires; must be called in a loop to handle spurious wakeups; belongs to java.lang.Object. Key distinction: sleep() is for simple delay/pausing; wait() is for inter-thread communication via the monitor protocol (producer-consumer). sleep() keeps locks; wait() releases them.

A daemon thread is a background thread that the JVM kills automatically when all user (non-daemon) threads have finished — even if the daemon is still running. Set before start(): thread.setDaemon(true). The main thread is always non-daemon. Use daemon threads for: (1) Garbage collection (the JVM's GC threads are daemon threads). (2) Background monitoring — heartbeat checkers, health probes. (3) Cache maintenance — TTL eviction, periodic cache warming. (4) Log flushing — periodic buffer flushes. (5) Connection pool maintenance. Never use daemon threads for: database writes, file writes, payment processing — any work that requires a clean shutdown because finally blocks and shutdown hooks may not run when daemon threads are killed.

Thread interruption is a cooperative cancellation mechanism. thread.interrupt() sets the target thread's interrupt flag. If the thread is blocked in sleep(), wait(), or join(), those methods immediately throw InterruptedException and clear the flag. If the thread is running, isInterrupted() returns true and the thread can check it. Correct handling of InterruptedException — two valid options: (1) Propagate: declare 'throws InterruptedException' in the method signature and re-throw. (2) Restore and stop: Thread.currentThread().interrupt() to restore the flag, then return/break. WRONG: catch (InterruptedException e) { /* do nothing */ } — this silently loses the interrupt signal; callers depending on it will never receive it. The rule: never swallow InterruptedException without restoring the flag.

join() causes the CALLING thread to block until the TARGET thread terminates (or timeout expires). It is used for sequencing — ensuring thread A's results are fully ready before thread B uses them. join() is guaranteed synchronization. sleep(ms) pauses the calling thread for a duration — no guarantee about any other thread's state. Using sleep() to 'wait for another thread' (Thread.sleep(500); // hopefully done) is a race condition — the other thread might finish in 200ms or 1000ms depending on system load. join() is always the correct tool for 'wait until another thread finishes'. join() also has a timeout version: join(ms) — blocks for at most ms milliseconds, then returns whether or not the target thread has finished (check with isAlive()).

Virtual threads (Project Loom, JEP 444, Java 21 GA) are JVM-managed lightweight threads not directly mapped to OS threads. Platform (traditional) threads: each maps to one OS thread (~1MB stack), expensive to create, a blocking call pins the OS thread. Virtual threads: managed by JVM scheduler, ~few KB initial stack, cheap to create (millions possible), blocking calls unmount the virtual thread from its carrier OS thread — the OS thread is freed to run other virtual threads. Ideal for: I/O-bound work (HTTP calls, database queries) where threads spend most time blocked. Not beneficial for: CPU-intensive computation (still needs real OS threads), ThreadLocal-based pooling patterns (virtual threads are too cheap to pool). Create: Thread.ofVirtual().start(task) or Executors.newVirtualThreadPerTaskExecutor().

UncaughtExceptionHandler is a callback interface (Thread.UncaughtExceptionHandler) that the JVM calls when a thread terminates due to an uncaught exception from run(). Without it, when a thread dies from an uncaught exception, the JVM prints a stack trace to System.err — which may be ignored or not captured in production log systems. The thread simply disappears silently from the application's perspective. Set per-thread: thread.setUncaughtExceptionHandler((t, ex) -> logger.error(...)); Set globally: Thread.setDefaultUncaughtExceptionHandler((t, ex) -> logger.error(...)); Critical for production: thread failures must be logged, alerted, and tracked. Thread pool executors suppress exceptions from tasks — combine with Future.get() or afterExecute() hook to catch those separately.

Practice Questions — Test Your Threading Knowledge

Attempt each question independently before reading the answer — active recall dramatically improves retention compared to passive reading.

1. What is the output of this code and why? Thread t = new Thread(() -> { System.out.println(Thread.currentThread().getName()); }, "WorkerThread"); t.run(); // Note: run(), not start()

Easy

✅ AnswerOutput: 'main'. Because t.run() is a regular method call — it executes the lambda on the CALLING thread, which is the main thread. Thread.currentThread().getName() returns 'main'. No new thread is created. If t.start() were called instead, the output would be 'WorkerThread' — because start() creates a new thread and invokes run() on it. This is the most fundamental threading mistake: confusing run() and start().

2. What states does a thread go through in this code? Thread t = new Thread(() -> { try { Thread.sleep(1000); } catch (InterruptedException e) { Thread.currentThread().interrupt(); } }); // State A: what is the state here? t.start(); // State B: (immediately after start) Thread.sleep(500); // State C: (after 500ms, while t is sleeping) t.join(); // State D: (after join returns)

Easy

✅ AnswerState A (before start): NEW — thread object created but start() not called. State B (immediately after start): RUNNABLE — start() has been called; thread is active. State C (after 500ms, while t is sleeping): TIMED_WAITING — Thread.sleep(1000) is in progress; t has been sleeping for ~500ms, will wake at ~1000ms. State D (after join): TERMINATED — t's sleep completed, run() returned, thread finished. join() returned only after t reached TERMINATED state.

3. Is there a bug? What is it? Thread worker = new Thread(() -> heavyComputation()); worker.start(); Thread.sleep(2000); // waiting for worker to finish System.out.println(result); // use result from heavyComputation

Easy

✅ AnswerYes — using Thread.sleep(2000) to 'wait' for the worker is a race condition. If heavyComputation() takes more than 2 seconds (under load, on a slow machine, during GC pause), result will be read before computation is complete — reading stale or null data. Fix: replace Thread.sleep(2000) with worker.join() — this blocks the main thread until worker is truly TERMINATED, regardless of how long the computation takes. join() is guaranteed; sleep() is a guess.

4. What does this output and what threading concept does it show? class Counter { static int count = 0; } Thread t1 = new Thread(() -> { for (int i = 0; i < 1000; i++) Counter.count++; }); Thread t2 = new Thread(() -> { for (int i = 0; i < 1000; i++) Counter.count++; }); t1.start(); t2.start(); t1.join(); t2.join(); System.out.println(Counter.count);

Medium

✅ AnswerThe output is unpredictable — it will be a number between 1000 and 2000, rarely exactly 2000. This demonstrates a race condition on the shared 'count' variable. 'count++' is NOT atomic — it is three operations: read count, increment, write back. When both threads execute these concurrently without synchronization, some increments are lost (one thread reads stale value, increments, writes — overwriting the other thread's increment). Fix: use AtomicInteger (count.incrementAndGet()) or a synchronized block. This is the foundational example of why shared mutable state requires synchronization in multithreaded code.

5. What is wrong with this InterruptedException handling? void processData() { try { Thread.sleep(5000); } catch (InterruptedException e) { System.out.println("Interrupted — continuing anyway"); // continue processing } doMoreWork(); // continues after interrupt }

Medium

✅ AnswerTwo problems: (1) The interrupt signal is silently swallowed — the catch block does nothing with the interrupt flag, which was cleared when InterruptedException was thrown. Code calling processData() via a thread that received interrupt() will have its interrupt signal permanently lost. (2) doMoreWork() runs after interruption — the caller intended to cancel the thread, but processing continues anyway. Fix: catch (InterruptedException e) { Thread.currentThread().interrupt(); // restore flag return; // or propagate up // do NOT continue processing } The interrupted thread should clean up and stop, not continue as if nothing happened.

6. Will this daemon thread keep the JVM alive? What will it print? public static void main(String[] args) { Thread daemon = new Thread(() -> { int i = 0; while (true) { System.out.println("Daemon tick: " + i++); try { Thread.sleep(200); } catch (InterruptedException e) { return; } } }); daemon.setDaemon(true); daemon.start(); System.out.println("Main done"); }

Medium

✅ AnswerThe JVM will NOT stay alive for the daemon. When main() returns, the main thread (the only non-daemon thread) terminates. The JVM immediately kills all daemon threads and exits. The output will be: 'Main done' and 0 to 2 daemon tick prints — depending on how quickly the JVM exits after main returns. The daemon may print 0, 1, or 2 ticks before being killed. If daemon.setDaemon(false) were used (or removed — default is non-daemon), the JVM would stay alive indefinitely running the while(true) loop.

7. Design a solution: You have 3 tasks (fetchUser, fetchOrders, fetchInventory) that can run concurrently. After all three complete, combine their results. Use Thread and join(). No ExecutorService.

Hard

✅ AnswerString[] results = new String[3]; Thread t1 = new Thread(() -> { // simulate fetch try { Thread.sleep(300); } catch (InterruptedException e) { Thread.currentThread().interrupt(); return; } results[0] = "User: Priya"; }, "FetchUser"); Thread t2 = new Thread(() -> { try { Thread.sleep(500); } catch (InterruptedException e) { Thread.currentThread().interrupt(); return; } results[1] = "Orders: [#101, #102]"; }, "FetchOrders"); Thread t3 = new Thread(() -> { try { Thread.sleep(200); } catch (InterruptedException e) { Thread.currentThread().interrupt(); return; } results[2] = "Inventory: 150 units"; }, "FetchInventory"); t1.start(); t2.start(); t3.start(); t1.join(); t2.join(); t3.join(); // All three done — safe to combine System.out.println(results[0] + ' | ' + results[1] + ' | ' + results[2]); // Total time: ~500ms (parallel) vs ~1000ms (sequential). Note: String[] is used for results to allow writing from Runnable lambda. In production, use AtomicReference or CompletableFuture.

8. What will this print? Is there a threading issue? class SharedCounter { private int value = 0; public int increment() { return ++value; } public int get() { return value; } } SharedCounter counter = new SharedCounter(); Thread[] threads = new Thread[10]; for (int i = 0; i < 10; i++) { threads[i] = new Thread(() -> { for (int j = 0; j < 100; j++) counter.increment(); }); threads[i].start(); } for (Thread t : threads) t.join(); System.out.println(counter.get());

Hard

✅ AnswerThe output is unpredictable — somewhere between 100 and 1000, almost never exactly 1000. This is a race condition. '++value' compiles to: read value, add 1, write back — three non-atomic operations. When 10 threads all execute these concurrently on the shared 'value' field, increments are lost due to interleaved reads and writes. For example: Thread-1 reads value=50, Thread-2 reads value=50, Thread-1 writes 51, Thread-2 writes 51 — one increment is lost. Fix: (1) 'synchronized int increment() { return ++value; }' (2) Replace int with AtomicInteger and use incrementAndGet(). (3) Use volatile — NOT sufficient here because volatile only ensures visibility, not atomicity of compound operations like ++.

Conclusion — Threads: The Foundation of Every Concurrent Java Application

Understanding threads at the single-thread level — how they are created, their lifecycle, how they pause, wait, interrupt, and finish — is the indispensable foundation for all concurrent Java programming. Every concurrency bug, every deadlock, every race condition ultimately comes down to threads violating the mental model you build here. Master the fundamentals before layering synchronization, locks, and thread pools on top.

The hallmarks of professional thread usage: always call start() (never run()), implement Runnable (not extend Thread), handle InterruptedException by restoring the flag, use join() for sequencing (not sleep()), name your threads meaningfully, set daemon status before start(), set an UncaughtExceptionHandler, and prefer ExecutorService over raw thread creation in production.

Concept	Key Method / Syntax	State / Effect	Critical Rule
Create thread	new Thread(runnable).start()	NEW → RUNNABLE	Always start(), never run()
Pause execution	Thread.sleep(ms)	RUNNABLE → TIMED_WAITING	Does NOT release locks; handle InterruptedException
Wait for thread	thread.join()	RUNNABLE → WAITING	Use join(), NOT sleep() for synchronization
Cancel a thread	thread.interrupt()	Sets interrupt flag	Restore flag in catch: currentThread().interrupt()
Background service	thread.setDaemon(true)	Killed on JVM exit	Set before start(); never for critical I/O work
Thread priority	thread.setPriority(1-10)	Scheduler hint only	OS-dependent; not a guarantee
Check state	thread.getState()	Thread.State enum	Six states: NEW RUNNABLE BLOCKED WAITING TIMED_WAITING TERMINATED
Virtual threads	Thread.ofVirtual().start(task)	JVM-managed lightweight	Java 21+; ideal for I/O-bound, not CPU-bound work

Your next step: Java Multithreading — where you'll learn how to safely coordinate multiple threads using synchronization, locks, volatile, atomic variables, and Java's rich java.util.concurrent package — building on every concept you've mastered here. ☕

Frequently Asked Questions — Java Single Thread

Two ways: (1) Extend Thread class and override run(). Limitation: consumes single inheritance slot. (2) Implement Runnable interface and pass to Thread constructor — preferred because it separates task logic from thread management, allows extending other classes, is compatible with ExecutorService, and supports lambda expressions. Since Java 8: new Thread(() -> { task }).start() — lambda implements Runnable directly.