Runnable vs Thread vs Callable: How to Start Threads

There are three interfaces you can implement, and in practice you should only use one of them.

Runnable has a single method, run(), and it returns nothing and cannot throw a checked exception. You pass it to new Thread(runnable) or submit it to an executor.

Callable has a single method, call(), which returns a value and may throw a checked exception. It is the interface you want whenever the work produces a result, because a thread that just runs cannot hand anything back — the only way to get data out of it is through shared mutable state, which is exactly the kind of bug you are trying to avoid.

Thread is the class itself. Extending it is legal but almost always the wrong choice, because Java has single inheritance and your class then cannot extend anything else. It also mixes up the work with the mechanism: the task and the thread that runs it are different concerns, and a Runnable can be run on any executor you like.

There is a fourth option worth naming for completeness: Thread.ofVirtual() and the virtual thread executors, which are now part of the language. Those change the cost model rather than the interface — you still supply a Runnable or a Callable, but the thread is cheap enough that you can have very many of them.

The advice for interviews is short. Implement Runnable or Callable, never extend Thread, and prefer an ExecutorService over creating threads by hand so that you get pooling, error handling and a clean shutdown for free.

Runnable cannot return a value and cannot throw a checked exception. Callable can do both — its method is called call rather than run — and it is the interface to use whenever the work produces something.

To get a result back you submit the Callable to an ExecutorService, which gives you a Future. The Future is a handle on the eventual result: get blocks until the task completes and returns the value, isDone tells you whether it has finished, and cancel asks for it to be stopped. Calling get on a task that threw throws an ExecutionException wrapping the original, which is how a checked exception from call reaches you.

import java.util.concurrent.Callable;
import java.util.concurrent.ExecutionException;
import java.util.concurrent.ExecutorService;
import java.util.concurrent.Executors;
import java.util.concurrent.Future;

public class Main {
    public static void main(String[] args) throws InterruptedException, ExecutionException {
        // A Runnable cannot return a value or throw a checked exception.
        Thread runnable = new Thread(() -> System.out.println("runnable ran"));
        runnable.start();
        runnable.join();

        // A Callable can, and it can be submitted to an ExecutorService.
        ExecutorService pool = Executors.newSingleThreadExecutor();
        try {
            Future<String> future = pool.submit(() -> {
                Thread.sleep(10);
                return "computed on " + Thread.currentThread().getName();
            });
            System.out.println("callable result : " + future.get());
        } finally {
            pool.shutdown();
        }
    }
}

The output shows the difference in practice. The Runnable simply runs and its output goes to the console. The Callable's value comes back through the Future, and the get call blocks until the work is done.

Two practical improvements over the basic Future. submit returns a plain Future, but the submitAsync methods on the executor return a CompletableFuture, which composes far better when you are chaining work. And a Future.get() with no timeout will block forever if the task hangs, so in a server you almost always want get(timeout, unit) and a sensible fallback.

One more distinction that catches people out. Thread itself implements Runnable, so you can pass a Thread to a thread pool. Do not do that — it makes the task and the executor's own thread management interact badly. Pass the Runnable directly.