نخ‌ها، Runnable/Callable و ExecutorهاThreads, Runnable/Callable & Executors

Come sit next to me. We are about to talk about one of those topics everyone dreads in interviews and bleeds over in production: concurrency. But I promise you — if you truly understand three things, this topic stops being scary magic and becomes something you hold in the palm of your hand. This whole chapter is those three things, built from the ground up, one small brick at a time.

First, a mental picture: a thread is like a worker who can follow one task. One worker means tasks happen one after another. Several workers means tasks can go forward at the same time. The entire argument of this chapter is about how you build those workers, how you hand them work, and how you politely say "that's enough, go home."

Part 0 — words you must know first

Before we jump into code, let's plant a few words we'll keep reusing, each with a small analogy. Keep these in the back of your mind and the rest of the chapter is easy.

• Thread: an independent unit of execution. A thread drives one sequence of instructions.
• OS scheduler: the part of the operating system that decides which thread runs on which core and for how long. You don't control it directly; you only make requests.
• Stack: each thread's private memory for local variables and the chain of method calls. Every thread has its own (typically ~1 MB reserved).
• System call: when your program asks the OS kernel for something (e.g., "make a new thread"). These are relatively slow.
• Blocking: when a thread stops and waits for something to happen — e.g., waiting for a database reply. While blocked, that thread does nothing but wait.
• Monitor lock: a lock acquired on an object via the synchronized keyword so only one thread at a time enters a critical section. Like a bathroom key only one person holds.
• CPU-bound vs I/O-bound: CPU-bound work means the thread is truly computing (compression, hashing). I/O-bound work means the thread mostly waits on something external (DB, network, disk). This distinction is the backbone of pool sizing.

Now that we have the tools, let's meet the thread itself.

Mental model: what a thread is and why it's expensive

A java.lang.Thread in Java is really a thin wrapper over an OS thread — we call that OS-level thread a platform thread, to distinguish it later from the virtual thread.

Why do I say it's expensive? When you create a thread, three costly things happen:

1. A large native stack is allocated (typically ~1 MB reserved).
2. The thread is registered with the OS scheduler.
3. All of this requires a system call.

Three questions frame this whole chapter. Answer these three and concurrency stops being mysterious:

1. What is the unit of work? Runnable (no result, no checked exception), Callable<V> (returns a value, may throw a checked exception), or the raw Thread subclass (almost never the right answer).
2. Who runs it, and on what thread? A bare Thread, or an ExecutorService backed by a pool.
3. How does it stop? Cooperatively, via interruption — because Java has no safe preemptive Thread.stop().

Let's unpack these three one by one.

Thread lifecycle & states

Over its life, a thread moves between several "states." Java keeps these in an enum called Thread.State. This enum is the ground truth — memorize it, because interviewers almost always probe the difference between WAITING and BLOCKED.

Now two traps, exactly where the interviewer puts a finger:

Runnable task = () -> System.out.println("on " + Thread.currentThread());
Thread t = new Thread(task);
t.run();    // BUG: runs on the *current* thread, no concurrency
t.start();  // correct: spawns a new thread

Keep the difference like this: run() is just an ordinary method that you call; it's start() that tells the OS "create a fresh thread and let that thread call run()."

Thread vs Runnable vs Callable/Future

Now the first question: what is the unit of work?

A golden rule: prefer composition over inheritance. That is, instead of extending Thread (extends Thread), write your work as a Runnable or Callable and hand it to a thread. Why? Because subclassing Thread couples your work to a thread forever and prevents you from reusing it in a pool. But a Runnable is a self-contained package of work that any thread can pick up and run.

The difference between Runnable and Callable:

• Runnable means "fire and forget": returns no value and its signature allows no checked exceptions.
• Callable<V> means "do something and give me the result back": returns a value of type V and may throw a checked exception.

// Runnable: fire-and-forget, no return, no checked exceptions in signature
Runnable r = () -> log.info("done");

// Callable: returns a value, may throw checked exceptions
Callable<Integer> c = () -> {
    return httpClient.fetchCount(); // may throw IOException
};

So if Callable returns a result but doesn't run right now — it finishes later on another thread — how do I get the result? That's where Future enters.

ExecutorService pool = Executors.newFixedThreadPool(4);
Future<Integer> f = pool.submit(c);
try {
    Integer n = f.get(2, TimeUnit.SECONDS); // blocks up to 2s
} catch (ExecutionException e) {
    // the task threw; e.getCause() is the ORIGINAL exception
    Throwable real = e.getCause();
} catch (TimeoutException e) {
    f.cancel(true); // true => interrupt the running thread
}

Three things about Future that trip people up — read these carefully, because all three can create silent bugs in production:

• f.cancel(true) only sets the interrupt flag; the task itself must cooperate (I'll explain in the interruption section below). cancel(false) prevents a not-yet-started task from running but won't interrupt a running one.
• get() is blocking. The calling thread stands there until the result is ready. If you want to chain work without standing still, prefer CompletableFuture, which is non-blocking and composable (with methods like thenApply, thenCompose, allOf).

The Executor framework

Now the second question: who runs the work? The professional answer: an Executor.

The Executor framework has a clean hierarchy, going from simple to complete:

• Executor — the most basic, has just one method: execute(Runnable).
• ExecutorService — extends it, adding submit, invokeAll, and lifecycle management (shutdown).
• ScheduledExecutorService — extends that further, adding delays and periodic execution.

But the real workhorse behind all of these is the class ThreadPoolExecutor. First, let's see why you shouldn't blindly trust the ready-made shortcuts.

The Executors factory — and why to distrust it

The Executors class has several convenient factory methods that build a pool for you in one line. The catch: several are dangerous in production, because they use either unbounded queues or unbounded thread counts:

Executors.newFixedThreadPool(n);   // LinkedBlockingQueue with NO capacity bound → OOM risk
Executors.newSingleThreadExecutor();// same unbounded queue
Executors.newCachedThreadPool();    // maxPoolSize = Integer.MAX_VALUE → unbounded threads

Let me make the danger concrete:

ThreadPoolExecutor: the seven parameters

Let's look at the full constructor. It takes seven parameters, and each is an engineering decision:

ThreadPoolExecutor pool = new ThreadPoolExecutor(
    4,                              // corePoolSize
    16,                             // maximumPoolSize
    60L, TimeUnit.SECONDS,          // keepAliveTime for threads above core
    new ArrayBlockingQueue<>(1000), // bounded work queue
    new ThreadFactoryBuilder()      // name threads! (Guava, or a hand-rolled factory)
        .setNameFormat("api-worker-%d").build(),
    new ThreadPoolExecutor.CallerRunsPolicy() // rejection handler
);

• corePoolSize (4): the number of always-kept threads, retained even when idle.
• maximumPoolSize (16): the most threads the pool is allowed to grow to.
• keepAliveTime (60s): threads above core that sit idle this long are torn down.
• work queue (ArrayBlockingQueue capacity 1000): where tasks wait for a free thread. Making this queue bounded is critical — you'll see why in a moment.
• ThreadFactory: the factory that creates threads; here we use it to name them.
• RejectedExecutionHandler: what to do with a new task when everything is full.

The submission algorithm of ThreadPoolExecutor is exactly this order and is worth memorizing, because it explains a notorious surprise:

1. If running threads < corePoolSize, start a new thread for the task (even if other threads are idle).
2. Else, try to enqueue the task.
3. If the queue is full, and running threads < maximumPoolSize, start a new (non-core) thread.
4. If the queue is full and threads == max, reject via the handler.

Rejection policies (RejectedExecutionHandler)

When the pool is fully saturated (queue full and threads at max), what do we do with a new task? You have four ready-made policies:

Pool-sizing math

Now we reach where senior candidates truly earn their stripes: how many threads should I use? The answer depends on one thing — is your work CPU-bound or I/O-bound?

CPU-bound case: CPU-bound work (compression, hashing, pure computation) keeps a core busy the whole time. Here, if you make more threads than cores, you gain nothing; you only add context-switch overhead (the cost the OS pays to set one thread aside and put another on the core):

threads ≈ number_of_cores        (or cores + 1 to cover the occasional page fault)

I/O-bound case: I/O-bound work spends most of its time waiting (on the DB, HTTP, disk). Here the story is completely different: you want enough threads that while several are waiting, others can use the CPU. Brian Goetz's famous formula (from Java Concurrency in Practice), which is really a restatement of Little's Law:

threads = cores × targetUtilization × (1 + waitTime / computeTime)

Let's pin it with a worked example. Suppose 8 cores, target 100% utilization, and each task waits 90 ms on the DB and computes for 10 ms (so wait/compute = 9):

threads = 8 × 1.0 × (1 + 90/10) = 8 × 10 = 80 threads

int cores = Runtime.getRuntime().availableProcessors();
double waitToCompute = 9.0; // measured from profiling, not guessed
int size = (int) (cores * (1 + waitToCompute));

One important practical note: you must get the waitToCompute number from real profiling, not from a guess.

ScheduledExecutorService

Sometimes you don't want the work to run right now; you want it "in 5 seconds" or "every 10 seconds." For these you have ScheduledExecutorService.

ScheduledExecutorService sched = Executors.newScheduledThreadPool(2);

sched.schedule(() -> log.info("once, after 5s"), 5, TimeUnit.SECONDS);

// fixed RATE: fires every 10s regardless of task duration (can pile up / overlap-guarded)
sched.scheduleAtFixedRate(this::poll, 0, 10, TimeUnit.SECONDS);

// fixed DELAY: waits 10s AFTER each completion — no pile-up
sched.scheduleWithFixedDelay(this::poll, 0, 10, TimeUnit.SECONDS);

You should feel the difference between these two methods in your bones, because it's a critical distinction:

• scheduleAtFixedRate: targets a fixed period. If a run exceeds the period, subsequent runs execute back-to-back to catch up.
• scheduleWithFixedDelay: inserts a fixed gap between the end of one run and the start of the next, so runs never overlap.

sched.scheduleWithFixedDelay(() -> {
    try { doWork(); }
    catch (Throwable t) { log.error("poll failed, will retry next tick", t); }
}, 0, 10, TimeUnit.SECONDS);

Shutdown: shutdown() vs shutdownNow()

An important note: you must shut down an ExecutorService yourself, or your JVM won't exit at all! Because pool worker threads are by default non-daemon (user) threads, and while alive they keep the JVM alive. (I'll explain daemon below.)

You have two ways to shut down:

Note that shutdownNow() interrupts running tasks (sets their interrupt flag) but cannot force-stop a task that ignores interruption. The canonical, correct graceful-shutdown idiom is this:

void shutdownGracefully(ExecutorService pool) {
    pool.shutdown(); // stop accepting, let queued tasks finish
    try {
        if (!pool.awaitTermination(30, TimeUnit.SECONDS)) {
            pool.shutdownNow(); // force: interrupt running tasks
            if (!pool.awaitTermination(10, TimeUnit.SECONDS))
                log.error("pool did not terminate");
        }
    } catch (InterruptedException e) {
        pool.shutdownNow();
        Thread.currentThread().interrupt(); // restore the flag
    }
}

The interruption model (cooperative cancellation)

We've reached the third question: how does a thread stop? And here Java made a deliberate, important decision: there is no safe way to forcibly kill a thread.

So cancellation in Java is cooperative. You only request cancellation (via interrupt()), and the target thread itself chooses to notice and cleanly wind down.

Interruption is really just a per-thread boolean flag, plus a few rules:

• thread.interrupt() — sets the flag (sends the signal).
• Thread.interrupted() — static; reads and clears the flag on the current thread.
• thread.isInterrupted() — reads the flag without clearing it.
• Blocking methods that declare throws InterruptedException in their signature (sleep, wait, join, BlockingQueue.take, Future.get) clear the flag and throw an InterruptedException when interrupted.

Now, when you catch an InterruptedException, you have exactly two correct responses:

1. Propagate it (let it bubble up to higher layers), or
2. Restore the flag and exit the work, so callers up the stack can still see the cancellation:

try {
    queue.take();
} catch (InterruptedException e) {
    Thread.currentThread().interrupt(); // NEVER swallow silently
    return; // stop the unit of work
}

One last note: blocking methods throw InterruptedException themselves, but if you have a CPU-bound loop that calls no blocking method, you must check the flag manually:

while (!Thread.currentThread().isInterrupted()) {
    doOneChunk();
}
// loop exits cleanly on interrupt — cooperative cancellation

ThreadLocal — and why it leaks in pools

ThreadLocal<T> gives each thread its own private copy of a variable. It's the standard mechanism for holding "per-request context" — like a transaction ID, the current user, or a SimpleDateFormat instance — without having to pass it by hand through every method.

private static final ThreadLocal<SimpleDateFormat> FMT =
    ThreadLocal.withInitial(() -> new SimpleDateFormat("yyyy-MM-dd"));

ThreadLocal values are stored in a map inside the Thread object itself, keyed by the ThreadLocal object. In pooled threads this creates two serious hazards:

try {
    RequestContext.CURRENT.set(ctx);
    handle(request);
} finally {
    RequestContext.CURRENT.remove(); // mandatory in pools
}

Daemon threads

Every thread in Java is either a user thread or a daemon thread. The key rule: the JVM exits precisely when the last non-daemon thread finishes — and at that moment, it abruptly abandons any daemon thread still running (with no guarantee that finally blocks run).

Thread t = new Thread(task);
t.setDaemon(true);   // must be set BEFORE start(), else IllegalThreadStateException
t.start();

• Use daemon threads for background infrastructure that should never keep the app alive: metrics flushers, cache-eviction timers, heartbeat pollers.
• Never use a daemon thread for work that must complete or must clean up (writing a file, flushing a transaction) — the JVM may kill it mid-write.
• A thread inherits its parent's daemon status by default. That's why Executors threads are user (non-daemon) threads and keep the JVM alive until you shut the pool down. If you want daemon threads in a pool, you must supply a ThreadFactory that calls setDaemon(true).

Virtual threads (Java 21+) — where the sizing math evaporates

And now the biggest change of recent years. Java 21 made virtual threads permanent. Let me build the intuition first.

So a virtual thread is a thread that the JVM itself schedules onto a small pool of carrier platform threads; when it blocks on I/O, instead of blocking an OS thread it unmounts — it parks in user space and frees its carrier. They're cheap enough that you can create millions.

// Each task gets its own virtual thread; NOT a pool to be sized
try (var exec = Executors.newVirtualThreadPerTaskExecutor()) {
    for (var req : requests)
        exec.submit(() -> handleBlocking(req)); // blocking calls are fine here
} // close() awaits all tasks (AutoCloseable)

But a few things still bite:

• Don't pool them. Making a newFixedThreadPool of virtual threads defeats the whole philosophy; always create one per task.
• They give no benefit for CPU-bound work. A virtual thread helps with waiting, not computing. For pure computation, keep the platform-thread pool sized to your cores.

Common pitfalls & gotchas (rapid fire)

Let's review all the traps we saw in this chapter in one place — these are exactly the ones that cause pain in production:

• Calling run() instead of start() — no new thread.
• Unbounded newFixedThreadPool queue → OOM under load.
• maximumPoolSize ignored because the queue is unbounded.
• Swallowing InterruptedException → uncancellable tasks.
• Forgetting ThreadLocal.remove() in a pool → leaked/stale context.
• Not naming threads → useless thread dumps in production. Always supply a ThreadFactory.
• Exceptions in submitted tasks silently lost until get().
• Scheduled task throws once → silently stops forever.
• Sharing a non-thread-safe object (SimpleDateFormat, Random under contention) across pool threads.

Best practices

1. Build ThreadPoolExecutor explicitly with a bounded queue + a chosen rejection policy; avoid the Executors unbounded factories in production.
2. Name your threads via ThreadFactory — future-you reading a thread dump will thank you.
3. Size CPU pools to cores; size I/O pools with the wait/compute formula, then cap at the real downstream bottleneck.
4. Always shutdown() + awaitTermination() + shutdownNow() on the way down.
5. Treat InterruptedException as a first-class signal: propagate or restore-and-exit, never swallow.
6. remove() every ThreadLocal in a finally when threads are pooled.
7. Prefer CompletableFuture/structured concurrency over chains of blocking get().
8. On Java 21+, use virtual threads for I/O-bound fan-out and stop hand-tuning pool sizes.

Interview Questions

Now let's practice everything you've learned in the shape of real interview questions. Answer each yourself first, then read the answer.

ExecutorService pool = Executors.newSingleThreadExecutor();
Future<?> f = pool.submit(() -> { throw new RuntimeException("boom"); });
System.out.println("submitted");
// no f.get() call
pool.shutdown();

Senior notes & advanced edge cases

You now hold the mental model of threads, Executors, pool sizing, cooperative cancellation, and virtual threads. Now we go one layer deeper — the layer you only learn after a few on-call nights and a couple of real post-mortems: the things that look correct in code and detonate under production load. This section repeats none of the earlier material; it only fills the gaps.

The memory model: happens-before you get for free

A subtle question: a task on thread B computes a value and writes it into an ordinary field (no volatile); thread A reads that field after future.get(). Is A guaranteed to see the fresh value, or might it see a stale/half-built one?

availableProcessors() lies inside containers

Every sizing formula from the previous chapter leans on "the number of cores." But where does that number come from? Runtime.getRuntime().availableProcessors(). The problem: in Kubernetes that number is often not what you think.

commonPool() and parallel streams share one pool

stream().parallel() and CompletableFuture.supplyAsync(task) (the no-executor overload) both run on one global pool: ForkJoinPool.commonPool(). That pool is small (core-count) and built for short CPU-bound work.

Two correct fixes:

// Fix 1: run the parallel stream inside a dedicated ForkJoinPool
ForkJoinPool custom = new ForkJoinPool(16);
List<R> out = custom.submit(() ->
    items.parallelStream().map(this::blockingCall).toList()
).get();

// Fix 2 (for CompletableFuture): always pass your own executor
CompletableFuture.supplyAsync(this::blockingCall, myIoPool);

CompletableFuture done right: where the callback runs

The chapter introduced CompletableFuture as "non-blocking and composable." The senior point is one question: which thread runs the callback?

• The non-Async form (e.g. thenApply): the callback runs on whichever thread completed the previous stage — or even on the calling thread if the stage was already complete. Unpredictable and dangerous for heavy work.
• The Async form with no executor (thenApplyAsync): on commonPool() — with the starvation trap above.
• The Async form with an executor: on your own pool. This is the correct production default.

CompletableFuture
    .supplyAsync(() -> fetchUser(id), ioPool)     // I/O on our pool
    .thenApplyAsync(this::enrich, cpuPool)         // CPU on a separate pool
    .exceptionally(ex -> User.anonymous())         // fallback
    .thenAccept(this::send);

Thread-starvation deadlock: a pool nested in itself

This is one of the sneakiest deadlocks and never shows up in tests, because it only occurs under load.

The sequence: your pool is bounded (say 10 threads). A task running on that pool submits subtasks to the same pool and then get()s, waiting on their results. If 10 parent tasks simultaneously occupy all 10 threads and each waits on its own subtask, no thread is left to run any subtask — everyone waits on everyone; total lock.

Diagram — why a bounded, self-nested pool deadlocks:

sequenceDiagram
    participant P as Parent tasks (fill all N threads)
    participant Q as Work queue
    participant C as Child tasks
    P->>Q: submit child, then block on get()
    Q-->>C: waiting for a free thread
    Note over P,C: all N threads held by parents<br/>no thread free to run children
    Note over P,C: parents wait children, children wait threads = deadlock

Observability and hooks

A pool you can't see will ambush you one day. Feed getActiveCount(), getQueue().size(), and getCompletedTaskCount() to Micrometer — a perpetually full queue means the pool is too small or the downstream is slow. And override ThreadPoolExecutor's beforeExecute/afterExecute: the perfect place to set/clear MDC, time execution, and catch the exceptions that submit silently swallows (afterExecute receives both the Runnable and the Throwable). Two more knobs: allowCoreThreadTimeOut(true) lets idle core threads be reclaimed (low-traffic pools), and prestartAllCoreThreads() warms the lazily-created core threads up front when first-request latency matters.

Choosing the queue type is an engineering decision too: ArrayBlockingQueue is the safe production default, PriorityBlockingQueue for a prioritized queue, and DelayQueue for scheduling — all in preference to the unbounded, dangerous LinkedBlockingQueue.

Spring @Async traps

@Async is the prettiest "go async" in the world — until one of these bites you:

The real virtual-threads playbook

The chapter said that with virtual threads you no longer size a pool. The senior's next question: so how do I protect a constrained downstream?

Semaphore db = new Semaphore(20);
db.acquire();
try { return jdbc.query(...); }
finally { db.release(); }

Build one manually with Thread.ofVirtual().name("job-", 0).start(runnable) or Thread.startVirtualThread(r). Two modern companions round out the fan-out pattern: structured concurrency (still a preview in JDK 25, JEP 505, now via StructuredTaskScope.open() with a Joiner) launches several subtasks in one scope so they all fail/cancel together and never leak a thread; and ScopedValue (finalized in JDK 25, JEP 506) is the immutable, cheaper ThreadLocal replacement for passing context to subtasks — no remove() needed, since its scope closes automatically.

Hard senior interview questions

Sources: ThreadPoolExecutor (JDK 17), Managing Throughput with Virtual Threads — inside.java, RejectedExecutionHandler — Baeldung