Threads, and What the OS Gives You

"To do two things at once is to do neither." — Publilius Syrus, Sentences (1st century BC)

A thread is the smallest thing an operating system will schedule. Java gives you an object that wraps one, a method to start it, and from that point your program has more than one place where execution is happening — which changes what "the program does X then Y" means, and invalidates most of the reasoning you have used until now.

This Part is the one Java interviews return to more than any other, and it is worth saying why before the mechanics. Concurrency is hard not because the APIs are complicated — Thread, start, join is three things — but because the reasoning is unfamiliar. Code that is obviously correct when one thread runs it can be wrong when two do, and the wrongness is intermittent, environment-dependent, and usually invisible in testing.

This chapter is about the primitive itself: what a thread costs, what you can observe about one, and the two ways to stop one — only one of which works. The chapters after it are about what goes wrong when two of them touch the same data.

What you can see from outside

Start with the object and its observable life.

A Thread object has a lifecycle and it is one-way. NEW before you start it, RUNNABLE once started, TERMINATED when the task returns — and calling start() on a terminated thread throws IllegalThreadStateException. A thread is not a reusable worker; it is one execution of one task, and the object is spent afterwards. That is most of the argument for thread pools, which reuse the operating system thread while giving each task a fresh run.

join() is the only coordination primitive in this block, and it is the one most worth knowing because it needs no shared state. Calling a.join() from thread B blocks B until A finishes. The timed form, join(50), returns after fifty milliseconds whether or not A has finished — so it needs an isAlive() check afterwards to know which happened, which the block shows.

Two notes on this playground before going further. It reports one processor, so nothing here runs genuinely in parallel; threads interleave on a single core. And getState() reports only NEW, RUNNABLE and TERMINATED — a real JVM also reports TIMED_WAITING while a thread sleeps, BLOCKED while it waits for a monitor, and WAITING on Object.wait(). Those three are real and are covered below as prose rather than as a block, because this runtime will not show them.

What a thread costs

Threads are not free, and the number people reach for is usually wrong by an order of magnitude.

A Java thread maps one-to-one onto an operating system thread. Creating one is a system call; each gets its own stack, by default around one megabyte of reserved address space, and the operating system keeps a scheduling entry for it. The consequences are concrete: a few thousand threads is a realistic ceiling on a normal machine, creating one takes on the order of tens of microseconds, and switching between them costs a kernel transition plus the cache disruption of running different code.

That cost is why the obvious design — one thread per request — stopped working as services got busier, and why thread pools exist. A pool pays the creation cost once and reuses the thread for many tasks, so the cost per task is a queue operation rather than a system call.

It is also why Java 21's virtual threads matter, and they are worth knowing about even though this runtime cannot run them. A virtual thread is scheduled by the JVM rather than the operating system, has a growable stack on the heap rather than a fixed one, and costs a few hundred bytes instead of a megabyte. Millions of them are practical. The programming model is deliberately identical — you still write Thread.ofVirtual().start(task), still join, still block — but blocking a virtual thread parks it and frees the carrier thread underneath, so the "one thread per request" design becomes viable again at a scale it never was before.

On Java 17, which is where this playground sits, you have platform threads and pools. The reasoning in this Part applies to both; what changes with virtual threads is how many you can afford, not what happens when two of them share data.

It is worth separating two words that get used interchangeably and mean different things. Concurrency is having several tasks in progress at once; parallelism is having several executing at the same instant. A single processor gives you concurrency and no parallelism — tasks take turns, and the turns are short enough that everything appears to progress together. Four processors give you up to four-way parallelism as well.

The distinction matters because the two solve different problems. Concurrency is what makes a server responsive while waiting on a database: the thread handling request A is blocked on I/O, so the processor runs request B. That is a win with one core and no arithmetic involved. Parallelism is what makes a computation finish sooner by splitting it, and it requires both multiple cores and work that divides.

Most server code wants concurrency and gets no benefit from parallelism, because it spends its time waiting rather than computing. Most data-processing code wants the opposite. Confusing them produces both of the classic mistakes: adding threads to a CPU-bound task on one core, which only adds switching overhead, and adding cores to an I/O-bound service, which leaves them idle.

Interruption is a request

Here is the part that surprises people: there is no way to stop a thread. There is only a way to ask.

interrupt() sets a boolean on the target thread and returns. That is all it does. A thread that never checks the flag is not interruptible, as the second worker demonstrates: it was interrupted and ran to completion anyway.

The two reading methods differ in a way that causes real bugs. isInterrupted() is an instance method that reads the flag and leaves it set. Thread.interrupted() is static, reads the flag for the current thread, and clears it. Code that uses the static form in a loop condition clears the flag on the first check, so a later check — or a library further down the stack — sees a thread that was never interrupted.

The missing half of the picture is what happens when the thread is blocked rather than looping. On a real JVM, interrupting a thread inside Thread.sleep(), wait(), join() or most blocking I/O causes that call to throw InterruptedException and clear the flag. I measured this on OpenJDK 17: the sleeping thread threw immediately, and isInterrupted() inside the catch block was false.

In this playground it does not happen — an interrupted sleep runs to completion — so the block above polls rather than blocks. That limitation is worth stating plainly because the clearing behaviour is the source of the rule everyone half-remembers: when you catch InterruptedException, the flag has already been cleared, so if you are not going to stop, you must put it back:

catch (InterruptedException e) {
    Thread.currentThread().interrupt();   // restore what the catch consumed
    return;                               // or actually stop
}

Swallowing an InterruptedException without restoring the flag discards a cancellation request that something above you issued — which is why Part II listed it among the things you must never catch silently.

How a thread dies, and who finds out

Interruption is the polite ending. The other one is an exception, and what happens then is not what people expect.

An exception that escapes a thread's task kills that thread and nothing else. The main thread carries on, the program does not exit, and the only evidence is a stack trace on stderr. Nothing returns a failure, nothing is thrown anywhere you can catch it, and in a service with a busy log it is entirely possible for a worker to die and nobody to notice for days.

setUncaughtExceptionHandler is how you find out. It receives the thread and the throwable, and it is where a log line with real context belongs. Thread.setDefaultUncaughtExceptionHandler installs one for every thread that has none of its own, which is the right place for a last-resort "something died" alert.

This is also the second half of the executor point from the next section. A task submitted to an executor does not reach these handlers — its exception is captured into the Future instead — so the two mechanisms cover different cases and a system usually wants both.

Daemon threads are the other half of a thread's relationship with the JVM. The JVM exits when the last non-daemon thread finishes; daemon threads are abandoned wherever they are, without running finally blocks. That makes them right for background housekeeping — a cache cleaner, a metrics flusher — and wrong for anything that must complete. The flag has to be set before start(), as the last section shows, and the default is non-daemon, which is why an un-shut-down executor keeps a finished program alive.

Pools, and why they exist

Creating a thread per task stops working quickly. The standard answer is a pool.

Six tasks ran on four threads, which is the point: the pool creates its threads once and feeds them work from a queue. The thread names make the reuse visible.

Future is the handle to a result that does not exist yet. get() blocks until it does, and — importantly — it carries failures across the thread boundary. A task that throws does not print a stack trace and vanish; the exception is captured and rethrown from get() wrapped in an ExecutionException, with the original available through getCause(). A task whose Future is never inspected can fail completely silently, which is one of the most common causes of "the job just stopped working" in scheduled systems.

Shutdown has two forms and both matter. shutdown() stops accepting new work and lets the queue drain; shutdownNow() additionally interrupts the running tasks and returns the ones never started. Neither blocks, which is why awaitTermination exists. And a pool that is never shut down keeps non-daemon threads alive, so the JVM will not exit — a surprisingly common reason for a program that finishes its work and hangs.

Per-thread state

One last primitive, because it solves a real problem and causes a famous leak.

A ThreadLocal gives each thread its own value for the same variable. That is genuinely useful for context that every layer needs and nobody wants to thread through forty signatures — a request id, a transaction, a security principal, a locale. It is how logging frameworks attach a correlation id to every line without changing any method.

The last section is the trap. A pooled thread outlives the task that ran on it, so a ThreadLocal set during one task is still set during the next — and the block shows a later task reading left-behind. In a server that means request two can see request one's context, which is a correctness bug and sometimes a security one. It also retains whatever the value points at for the life of the thread, which is the leak shape from Part I's chapter on garbage collection.

The rule is unconditional: set a ThreadLocal in a try, remove it in the finally. Frameworks that manage context for you do exactly this, which is why Spring's RequestContextHolder and MDC-based logging work correctly on pooled threads and a hand-rolled equivalent usually does not.

Common Mistakes

1. Expecting interrupt() to stop a thread. It sets a flag. A thread that never checks it, and is not blocked in an interruptible call, runs to completion.

2. Using Thread.interrupted() in a loop condition. The static form clears the flag as it reads it, so a later check — or a library below you — sees a thread that was never interrupted. Use isInterrupted() unless you mean to consume it.

3. Swallowing InterruptedException. Catching it clears the flag, so if you do not stop you must restore it with Thread.currentThread().interrupt(), or the cancellation is lost.

4. Reusing a Thread object. TERMINATED is final; calling start() again throws IllegalThreadStateException. Create a new one, or use a pool.

5. Submitting to an executor and ignoring the Future. A task that throws fails silently; the exception is held in the Future and surfaces only when something calls get().

6. Never shutting an executor down. Its threads are not daemons by default, so the JVM will not exit and the program appears to hang after finishing its work.

7. Calling shutdown() and assuming it waited. It returns immediately; awaitTermination is what blocks, and shutdownNow is what interrupts the running tasks.

8. Setting a ThreadLocal on a pooled thread without removing it. The thread outlives the task, so the next task inherits the value and the referenced object is retained.

9. One thread per request on platform threads. The ceiling is a few thousand and each costs about a megabyte of stack. Use a pool, or virtual threads on Java 21.

10. Relying on thread priorities. They are hints passed to an operating system scheduler that may ignore them entirely, and behaviour differs by platform.

Interview Corner

Hands-on

Summary

• A thread is the unit the operating system schedules, and a Java platform thread maps one-to-one onto one — a system call to create, about a megabyte of stack, a few thousand as a practical ceiling.
• A Thread object is single-use. TERMINATED is final and start() on a spent thread throws, which is most of the argument for pools.
• join() waits without shared state, and the timed form needs an isAlive() check afterwards to know whether it finished or timed out.
• interrupt() sets a flag and returns. A thread that neither polls it nor blocks in an interruptible call is not stoppable.
• isInterrupted() reads the flag; Thread.interrupted() reads and clears it — and using the static form in a loop condition silently consumes the cancellation.
• Catching InterruptedException clears the flag, so restore it with Thread.currentThread().interrupt() unless you are actually stopping.
• A pool reuses threads across tasks, turning a system call per task into a queue operation.
• A Future carries the task's exception across the thread boundary, so a task whose Future is never inspected can fail completely silently.
• shutdown() returns immediately — awaitTermination blocks, shutdownNow interrupts — and a pool never shut down keeps the JVM alive.
• A ThreadLocal on a pooled thread outlives its task, so set it in a try and remove() it in the finally, or the next request inherits it.

You now have more than one thread. The next chapter is about what that does to the guarantees you have been relying on — the Java Memory Model, happens-before, and why a value written by one thread may never be seen by another even when nothing is obviously wrong.