Creating threads: Thread, Runnable and Callable

For this lesson, we'll cover every way to define and launch work: subclassing Thread, passing a Runnable, returning a value with Callable, the Java 21 builders, and handing tasks to an executor. Interviewers like this topic because the code is tiny but the follow-ups are sharp: "what if I call run()?", "can I start it twice?", "where did my exception go?". Those three questions separate people who have used threads from people who have debugged them.

01Picture it first: the job ticket and the worker

Think of a print shop. A job ticket says what to print; a worker picks up the ticket and does it. You can write a ticket without hiring anyone, and one worker can handle a thousand tickets in a day. Runnable and Callable are tickets. Thread is a worker, and an ExecutorService is the shop manager who keeps a few workers busy.

Extending Thread is like printing the instructions on the worker's uniform: it works, but that worker can only ever do that one job. That's the core reason modern code passes tasks to threads instead of subclassing them.

The other half of the picture is the difference between doing the job yourself and handing it over. Here's the same Thread object used two ways. Calling run() is doing the dishes yourself: nothing else happens in the house until you're done. Calling start() is asking your flatmate to do them while you get on with something else.

Fig. 1

Calling run() puts the task on the main thread's own stack, while start() creates a second thread with its own stack that runs the task

02Three ways to define a task

In plain words, there are only two kinds of errand. "Go water the plants" is a Runnable: you send someone off and don't expect anything back. "Go count how many plants need water and tell me" is a Callable: you expect an answer, and you want to hear about it if something went wrong on the way. Extending Thread is the third, older option, where the errand and the person doing it are welded together.

Here's the smallest program that shows all three shapes, plus the two ways to run a Callable:

import java.util.concurrent.*;

public class ThreeWays {

    static class ReportThread extends Thread {          // way 1: subclass Thread
        ReportThread() { super("report-thread"); }
        @Override public void run() { log("subclass run()"); }
    }

    static void log(String msg) {
        System.out.println(Thread.currentThread().getName() + ": " + msg);
    }

    static void sendEmail() { log("method reference"); }

    public static void main(String[] args) throws Exception {
        Thread t1 = new ReportThread();
        Thread t2 = new Thread(() -> log("lambda Runnable"), "lambda-thread");   // way 2
        Thread t3 = new Thread(ThreeWays::sendEmail, "mail-thread");
        t1.start(); t2.start(); t3.start();
        t1.join(); t2.join(); t3.join();

        Callable<Integer> countOrders = () -> {                                  // way 3
            log("callable computing");
            return 42;
        };
        FutureTask<Integer> futureTask = new FutureTask<>(countOrders);
        new Thread(futureTask, "futuretask-thread").start();
        System.out.println("FutureTask result: " + futureTask.get());   // blocks

        try (ExecutorService pool = Executors.newFixedThreadPool(2)) {   // AutoCloseable since 19
            Future<Integer> f = pool.submit(countOrders);
            System.out.println("pool result: " + f.get(1, TimeUnit.SECONDS));
        }
    }
}

One run printed (the first three lines come out in any order):

mail-thread: method reference
lambda-thread: lambda Runnable
report-thread: subclass run()
futuretask-thread: callable computing
FutureTask result: 42
pool-1-thread-1: callable computing
pool result: 42

Notice four things:

1. Runnable is a functional interface, so a lambda or a method reference (ThreeWays::sendEmail) is a complete task. An anonymous new Runnable() { public void run() {...} } does the same with more noise; the one real difference is that this inside an anonymous class means the anonymous object, while in a lambda it means the enclosing instance.
2. Callable<V>.call() returns a value and is declared throws Exception, so checked exceptions are allowed. Runnable.run() returns void and can't throw checked exceptions.
3. A Callable can't go into new Thread(...) directly. Wrap it in a FutureTask, which implements both Runnable and Future, or submit() it to an executor.
4. get() blocks until the result is ready. get(1, TimeUnit.SECONDS) gives up with TimeoutException. If call() threw, get() throws ExecutionException with the original as its cause. Cancellation and composition belong to the "Future and Callable" lesson.

Fig. 2

A Thread subclass, a Runnable and a Callable each reach a thread by a different route, and only the Callable path hands back a value or an ExecutionException

Why Runnable beats extending Thread

• Single inheritance. class Job extends Thread burns your only superclass on plumbing. class Job extends BaseJob implements Runnable keeps it.
• Task separate from worker. A Runnable says what to do; the Thread decides how it runs (name, daemon flag, stack size). Mixing them makes both harder to test: you can call task.run() in a unit test with no threads at all.
• Reuse. The same Runnable goes to new Thread, Thread.ofVirtual(), pool.execute or pool.submit without changes. A Thread subclass can only ever be started once, by itself.

Extending Thread is fine for a tiny demo or when you genuinely customise thread behaviour. For application work, my default is a Runnable or Callable and an executor.

03start() vs run(), and starting twice

public class StartVsRun {

    public static void main(String[] args) throws InterruptedException {
        Runnable task = () -> System.out.println("task runs on: " + Thread.currentThread().getName());

        Thread worker = new Thread(task, "worker-1");
        System.out.println("state before: " + worker.getState());

        worker.run();     // a plain method call on main's stack
        worker.start();   // a new OS thread, which then calls run()
        worker.join();
        System.out.println("state after join: " + worker.getState());

        try {
            worker.start();   // second start on the same Thread object
        } catch (IllegalThreadStateException e) {
            System.out.println("second start(): " + e);
        }
    }
}

state before: NEW
task runs on: main
task runs on: worker-1
state after join: TERMINATED
second start(): java.lang.IllegalThreadStateException

run() is an ordinary method. Calling it pushes a frame on your stack, runs the task on your thread and returns; no thread is created, and the caller waits for it. start() is the only call that makes a new thread. join() makes the caller wait until that thread finishes, which is why "state after join" is reliably TERMINATED.

A Thread object is single-use. start() checks an internal status field and throws IllegalThreadStateException if the thread was ever started, even after it has terminated. To run the work again, create a new Thread with the same Runnable, or better, submit the task to a pool that reuses its threads for you.

04What start() really does

Here's the everyday version first. new Thread(task) is writing a job offer: it's on paper, nobody has been hired yet. start() is the moment HR actually hires the person and gives them a desk. The desk is the thread's stack, HR is the operating system, and if the building is full, HR says no. Now the real steps.

Let's follow one start() call for a platform thread on Linux, using the JDK 21 sources (Thread.java, HotSpot's JVM_StartThread in jvm.cpp and os_linux.cpp).

Fig. 3

start() checks the thread status, calls native start0, HotSpot asks the OS for a native thread with an -Xss sized stack, start() returns while the new thread enters Thread.run

1. new Thread(task) allocates a plain Java object on the heap, state NEW. No OS resource exists yet.
2. start() synchronizes on the thread, checks the status is still "never started" and calls the native start0().
3. HotSpot's JVM_StartThread creates its C++ JavaThread and asks the OS for a native thread. On Linux that's pthread_create, with a stack size from the Thread constructor's stackSize hint or else -Xss (1 MB on Linux/x64, 2 MB on Linux/AArch64 and macOS/AArch64).
4. If the OS refuses (process or user thread limits, container PID limits, no address space for the stack), start() throws OutOfMemoryError: unable to create native thread: possibly out of memory or process/resource limits reached. Older JDKs said "unable to create new native thread".
5. The thread is marked RUNNABLE and released, and start() returns at once. It does not wait for run() to begin.
6. The new thread begins in the JVM's thread entry routine, which calls Thread.run(), which calls your task. When run() returns or throws, the thread is TERMINATED and its OS thread and stack are released.

The JLS gives you one guarantee for free here: a call to start() happens-before every action in the started thread (JLS §17.4.5). Whatever you wrote before start(), the new thread sees.

05The Java 21 way: Thread.Builder

Java 21 (JEP 444) added builders that make the thread's configuration explicit and give you virtual threads with the same API. Think of a builder as a form you fill in once (name pattern, daemon or not, platform or virtual) and then use to stamp out as many threads as you like, all set up the same way.

import java.util.concurrent.*;

public class Builders {

    static void show() {
        Thread t = Thread.currentThread();
        System.out.println("name='" + t.getName() + "' virtual=" + t.isVirtual() + " daemon=" + t.isDaemon());
    }

    public static void main(String[] args) throws Exception {
        Thread.Builder.OfPlatform workers = Thread.ofPlatform().name("worker-", 0).daemon(false);
        Thread a = workers.start(Builders::show);       // worker-0
        Thread b = workers.unstarted(Builders::show);   // worker-1, state NEW
        System.out.println("b is " + b.getState());
        b.start();
        a.join(); b.join();

        Thread v = Thread.ofVirtual().name("vt-", 0).start(Builders::show);
        v.join();
        Thread.startVirtualThread(Builders::show).join();   // unnamed: ""

        ThreadFactory factory = Thread.ofPlatform().name("orders-", 1).factory();
        try (ExecutorService pool = Executors.newFixedThreadPool(2, factory)) {
            pool.submit(Builders::show).get();
        }
        try (ExecutorService vexec = Executors.newVirtualThreadPerTaskExecutor()) {
            vexec.submit(Builders::show).get();
        }
        System.out.println("default name: " + new Thread(() -> {}).getName());
    }
}

b is NEW
name='worker-1' virtual=false daemon=false
name='worker-0' virtual=false daemon=false
name='vt-0' virtual=true daemon=true
name='' virtual=true daemon=true
name='orders-1' virtual=false daemon=false
name='' virtual=true daemon=true
default name: Thread-0

Notice five things:

1. name(prefix, start) numbers threads per builder: worker-0, worker-1. unstarted() returns a configured thread in state NEW for you to start later.
2. Virtual threads are always daemon and have an empty name unless you set one. Thread.ofVirtual().start(r) and Thread.startVirtualThread(r) do the same thing.
3. factory() turns a builder into a ThreadFactory, the interface every executor uses to create its threads, so pool threads get your names. The factory is safe to share between threads.
4. ExecutorService is AutoCloseable since Java 19. close() stops new submissions and waits for every submitted task to finish, so try-with-resources is the clean scope for short-lived pools. newVirtualThreadPerTaskExecutor() (Java 21) starts one new virtual thread per task.
5. Unnamed platform threads get Thread-N, from a JVM-wide counter. Builder-named threads don't consume it, which is why this one is Thread-0. Pools from Executors default to pool-N-thread-M.

Name every thread you create. A thread dump or log line that says pool-7-thread-3 tells you nothing at 3 a.m.; payment-retry-3 tells you where to look. The classic constructors take a name too: new Thread(task, "payment-retry-3").

06Passing data in, getting results out

Think of handing a courier a sealed envelope: once it leaves your hand, nobody should be able to swap what's inside. That's the rule for passing data to a thread.

Data goes in through the constructor of your task or through captured variables. A lambda can capture a local only if it's effectively final, which is a feature: the thread gets a value nobody can reassign under it.

String orderId = request.orderId();                       // effectively final
Thread t = Thread.ofPlatform().name("order-" + orderId)
                 .start(() -> fulfil(orderId));            // captured by value

Results come out best through a Callable and its Future: get() hands you the value with the right memory visibility built in. Writing to a shared field and having another thread poll it without synchronization is a data race: the reader may never see the write. Reading a field after t.join() returns is safe, because a thread's last action happens-before join() returns (JLS §17.4.4), but that only works for one-shot threads you own. The "Happens-before" lesson makes this precise.

07When a thread throws

An uncaught exception ends only the thread that threw it. The JVM calls the thread's UncaughtExceptionHandler; if you set none, it falls back to Thread.setDefaultUncaughtExceptionHandler, and if that's unset too, the thread group prints Exception in thread "name" and the stack trace to System.err. Other threads, including main, carry on.

Executors add a twist. Here's the program I use to show it:

import java.util.concurrent.*;

public class LostException {

    public static void main(String[] args) throws Exception {
        Thread t = new Thread(() -> { throw new IllegalStateException("boom in plain thread"); }, "plain");
        t.start();
        t.join();
        System.out.println("main is still alive");

        Thread.setDefaultUncaughtExceptionHandler((th, ex) ->
                System.out.println("handler saw '" + ex.getMessage() + "' on " + th.getName()));
        try (ExecutorService pool = Executors.newFixedThreadPool(1)) {
            pool.submit(() -> { throw new IllegalStateException("boom in submit"); });   // Future ignored
            Future<?> kept = pool.submit(() -> { throw new IllegalStateException("boom, get() called"); });
            try {
                kept.get();
            } catch (ExecutionException e) {
                System.out.println("get() threw ExecutionException, cause: " + e.getCause().getMessage());
            }
            pool.execute(() -> { throw new IllegalStateException("boom in execute"); });
        }
        System.out.println("done (nobody ever heard about 'boom in submit')");
    }
}

Exception in thread "plain" java.lang.IllegalStateException: boom in plain thread
	at LostException.lambda$main$0(LostException.java:6)
	at java.base/java.lang.Thread.run(Thread.java:1516)
main is still alive
get() threw ExecutionException, cause: boom, get() called
done (nobody ever heard about 'boom in submit')
handler saw 'boom in execute' on pool-1-thread-1

I ran this on JDK 26; on 21 the Thread.java line number differs. The last two lines can swap, because the dying pool worker reports its exception after the pool has already counted it as finished. To handle one thread's failures differently, call t.setUncaughtExceptionHandler(...) on it before start(), or set it once on a builder with uncaughtExceptionHandler(...).

Here's the layman's picture. execute() is a courier who rings your doorbell when a delivery fails: you can't miss it. submit() is a courier who quietly drops the failure note in your letterbox. If you never open the letterbox (call get()), you never find out.

submit() wraps your task in a FutureTask, which catches everything and stores it in the Future. If nobody calls get(), the exception is gone: no log, no handler, no trace. execute() doesn't wrap, so the exception escapes, kills that pool worker (the pool replaces it) and reaches the uncaught handler. My rule: use execute() for fire-and-forget work, or submit() and always consume the Future; and in either case catch and log inside the task.

08Real world

09Advanced: costs, constructors and comparisons

import java.util.ArrayList;
import java.util.List;

public class ThreadCost {

    static long nanosPerThread(Thread.Builder builder, int n) throws InterruptedException {
        List<Thread> threads = new ArrayList<>(n);
        long start = System.nanoTime();
        for (int i = 0; i < n; i++) threads.add(builder.start(() -> { }));   // empty task
        for (Thread t : threads) t.join();
        return (System.nanoTime() - start) / n;
    }

    public static void main(String[] args) throws InterruptedException {
        for (int round = 1; round <= 3; round++) {   // round 1 includes JIT warm-up
            System.out.printf("round %d: platform %,6d ns/thread   virtual %,5d ns/thread%n", round,
                    nanosPerThread(Thread.ofPlatform(), 10_000), nanosPerThread(Thread.ofVirtual(), 10_000));
        }
    }
}

round 1: platform 35,581 ns/thread   virtual 1,932 ns/thread
round 2: platform 35,162 ns/thread   virtual 1,340 ns/thread
round 3: platform 35,109 ns/thread   virtual 1,416 ns/thread

Some depth that separates strong answers:

• The full constructor is Thread(ThreadGroup group, Runnable task, String name, long stackSize). stackSize is a hint the Javadoc says some platforms ignore; prefer -Xss or Thread.ofPlatform().stackSize(...). Thread groups are legacy: since Java 19 they're kept mostly for compatibility, so don't design around them.
• run() on a virtual thread does nothing when you call it directly (Java 21 Javadoc). One more reason never to call run() yourself.
• Pool threads are non-daemon by default, so a forgotten newFixedThreadPool keeps the JVM alive after main ends. Try-with-resources or shutdown() fixes it.
• Java 19 added Future.state(), resultNow() and exceptionNow(), handy for inspecting finished futures without the checked get() dance.
• getId() is deprecated since Java 19; use threadId().

Thread vs Runnable vs Callable vs Thread.Builder vs ExecutorService

10How to say it in the interview

When I ask this, I'm listening for three things. Do you keep task and thread separate and know why Runnable wins over extending Thread? Do you know that only start() creates a thread, with a one-way NEW to started transition? And do you know where exceptions and results go once an executor is involved?

Three questions come up almost every time; here's how I'd answer each in two sentences.

• "Runnable vs Callable?" Runnable.run() returns nothing and can't throw checked exceptions; Callable<V>.call() returns a V and may throw Exception. You run a Callable through ExecutorService.submit() or a FutureTask, and read the result or the wrapped ExecutionException with Future.get().
• "What happens if you call run() instead of start()?" The task runs as a normal method call on the current thread, so Thread.currentThread().getName() prints the caller's name and nothing runs in parallel. No OS thread is created and the Thread stays NEW.
• "Can you start a thread twice?" No. The second start() throws IllegalThreadStateException, even after the first run finished; create a new Thread or use a pool.

Here's how this might look if you sketch it on the whiteboard: