نخ‌های مجازی (Loom) و همزمانی ساخت‌یافتهVirtual Threads (Project Loom) & Structured Concurrency

Imagine you run a busy restaurant and you assign one dedicated waiter to every single customer. It's beautiful and simple — each waiter watches only their own table. But waiters are expensive; you can't hire a hundred thousand of them. That is the whole story of this chapter: how Java made "one waiter per customer" suddenly cheap enough to scale to millions. It's one of the biggest shifts in Java of the last decade, and it shows up in nearly every senior interview.

Part 0 — words you must know

Let's build a few terms with analogies first, so none of them are ever dropped cold later.

• Thread: an independent line of execution in your program. Like one worker who can follow a task from top to bottom.
• OS thread: a worker the operating system itself hires and schedules. Real, expensive, and limited.
• Platform thread: the classic Java thread. Really just a thin wrapper around one OS thread — a 1:1 relationship. When you write new Thread(...), this is what you've always gotten.
• Blocking: when a thread hits a wall and waits — for a database reply, a network response, a file read. During that time it does nothing but stand there.
• I/O: input/output — anything that happens outside the CPU: network, disk, database. Almost always slow and full of waiting.
• Call stack: the notebook that says exactly where in the code the thread is and which methods called which. Each method's depth and local variables live here.
• Context switch: when the OS takes a worker off one job and puts them on another. Like substituting a player; it isn't free, it costs time.
• Throughput vs latency: throughput is "how many requests per second can you serve"; latency is "how long does one request take." These are different, and confusing them is a classic interview mistake.

What problem are we actually solving?

For twenty years the dominant Java server architecture was thread-per-request: dedicate one OS thread to a request, write plain blocking code (socket.read(), jdbc.executeQuery()), and let the thread park while I/O completes.

Why is this style so beloved? Because it's natural. The call stack is the request — glance at the stack and you know where the request is. Exceptions propagate naturally (an error travels up the call chain until someone catches it). Thread-locals carry context like "current user" with zero fuss. It's easy to write, read, debug, and profile.

The problem is cost. A platform thread is a thin wrapper over an OS thread, and OS threads are expensive: each reserves a large stack (typically ~1 MB of address space by default), scheduling is done by the kernel, and context switches are relatively heavy. On a typical machine you can realistically run a few thousand of them.

Now look at the consequence: if each request blocks on I/O for most of its lifetime, your throughput is capped not by CPU or by the downstream service, but by how many threads you can afford. This is why we invented thread pools (reuse a few waiters over and over), and why the industry drifted toward reactive/async programming (CompletableFuture, Reactor, RxJava): those styles let a handful of threads service tens of thousands of concurrent requests by never blocking.

But reactive charges a heavy price: developer ergonomics. You lose the stack (it no longer tells the request's story), you lose easy debugging, and your logic fragments into callbacks or operator chains.

Virtual threads (Project Loom) are the JDK's answer to this dilemma: keep the simple blocking programming model, but make threads so cheap that "one thread per request" scales to millions. You get the throughput of async with the ergonomics of blocking code — the best of both worlds.

Platform threads vs virtual threads

Let's see the difference in a short table, then unpack it:

Platform thread          Virtual thread
─────────────────        ──────────────────────────────
1:1 with OS thread       many:few  (M:N over carriers)
~1 MB stack (fixed)      small, resizable heap stack
kernel-scheduled         JDK-scheduled (ForkJoinPool)
~few thousand max        millions
expensive to create      cheap; disposable, not pooled

Here's the surprising part: a virtual thread is also a java.lang.Thread — same class, same API. The difference is who manages its execution: not the OS, but the JDK itself.

Let's build the mechanism with an analogy, because it's the heart of the whole topic.

Now in technical language: when a virtual thread runs, the JDK mounts it onto a carrier thread (a platform thread from a dedicated ForkJoinPool, by default sized to the number of CPU cores). When the virtual thread hits a blocking operation that Loom understands (most java.* blocking I/O, LockSupport.park, Thread.sleep, BlockingQueue, NIO, etc.), the JDK unmounts it: its continuation (the stack) is copied off to the heap and the carrier is freed to run some other virtual thread. When the I/O completes, the virtual thread is re-mounted (possibly onto a different carrier) and resumes exactly where it left off.

Creating them

// 1. Direct factory — a virtual thread, started immediately
Thread vt = Thread.ofVirtual().start(() -> System.out.println("hi from " + Thread.currentThread()));
vt.join();

// 2. Unstarted, or with a name
Thread t = Thread.ofVirtual().name("worker-", 0).unstarted(task);

// 3. The idiomatic server pattern: an executor that spawns a NEW virtual
//    thread PER TASK. This is NOT a pool — there is nothing to size.
try (var executor = Executors.newVirtualThreadPerTaskExecutor()) {
    for (int i = 0; i < 1_000_000; i++) {
        executor.submit(() -> {
            Thread.sleep(Duration.ofSeconds(1)); // blocks the VT, not a carrier
            return fetchFromDb();
        });
    }
} // close() waits for all tasks — try-with-resources = structured lifetime

Notice three things. First, Thread.ofVirtual() builds the new kind and Thread.ofPlatform() builds the old kind explicitly. Second, Thread.currentThread().isVirtual() tells you which kind you're on right now. Third and most important: look at the comment on #3 — newVirtualThreadPerTaskExecutor() is not a pool. For every task you submit it creates a brand-new virtual thread and then throws it away. We wrote a million-iteration loop here without worry; in the platform-thread world that code would bring the machine to its knees.

Three golden rules that flow straight from the design

All three are consequences of the same principle: "creation is cheap, blocking is free."

1. Never pool virtual threads. Pools exist to amortize expensive resource creation. Virtual threads are cheap to create and meant to be disposable — one per task. Use newVirtualThreadPerTaskExecutor(), not a fixed pool. Pooling virtual threads is like buying a sterilizing-and-recycling machine for disposable paper napkins.

2. Don't block a platform thread to limit concurrency — use a semaphore. If a downstream can only take 10 concurrent connections, don't create a pool of 10 platform threads; run unlimited virtual threads and gate the scarce resource with new Semaphore(10). (A semaphore is like a box of 10 keys: anyone entering the room must take a key and return it on the way out; the 11th person waits at the door.)

3. Don't cache expensive objects in thread-locals. With millions of threads, a per-thread cache is a memory disaster. Thread-locals still work (and are how context is propagated), but stop using them as a per-thread object pool.

Pinning — the one thing that can wreck you

So far we've said unmounting is Loom's magic. But that magic has a condition: the JDK must be able to lift the stack off the carrier and put it on the heap. In two situations it can't, and the virtual thread stays pinned to its carrier even while blocked — meaning it does tie up a platform thread, reintroducing the very scaling limit we came here to escape.

The two situations where pinning happens:

1. Blocking inside a synchronized block/method (on JDK 21–23).
2. Blocking inside a native frame (a JNI call, or certain FFM downcalls).

Case 1 is the notorious one. Pre-JDK 24, if a virtual thread held a monitor via synchronized and then blocked on I/O, it pinned its carrier. (A "monitor" is the invisible lock every Java object carries and that synchronized uses.) With enough pinned virtual threads you exhaust the carrier pool → throughput collapses, and in the worst case you get starvation or deadlock: no carrier is free to run the thread that would release the lock, and everyone waits on that same lock.

private final Object lock = new Object();

// BAD on JDK 21-23: the blocking read runs while holding the monitor → PIN
synchronized void badWrite(Socket s) throws IOException {
    s.getOutputStream().write(payload); // blocks WHILE pinned
}

// GOOD everywhere: use a j.u.c.Lock. ReentrantLock does NOT pin — Loom
// understands it and can unmount the virtual thread while it waits.
private final ReentrantLock lock = new ReentrantLock();
void goodWrite(Socket s) throws IOException {
    lock.lock();
    try { s.getOutputStream().write(payload); }
    finally { lock.unlock(); }
}

The difference is subtle but crucial: synchronized is a low-level language construct that Loom can't unwind the stack across, whereas ReentrantLock (from java.util.concurrent.locks) is pure Java code that Loom understands and can unmount a virtual thread waiting on.

How do you find pinning? Run with -Djdk.tracePinnedThreads=full (on JDK 21) or, better, a JFR (Java Flight Recorder) recording — the jdk.VirtualThreadPinned event fires on every pin with a stack trace, so you see exactly which line is guilty. And if you have genuine native pinning you can't remove, you can raise the carrier pool with -Djdk.virtualThreadScheduler.parallelism to get more carriers.

When NOT to use virtual threads

Virtual threads are built for scaling concurrency of blocking, I/O-bound tasks. If you miss that, you might use them everywhere and wonder why you gained nothing. They are the wrong tool when:

• The work is CPU-bound. A virtual thread gives you nothing for pure computation — you still need one carrier per busy core, and the ideal is a bounded pool sized to cores (e.g. a ForkJoinPool). Remember: Loom improves waiting, not computing. If a thread never blocks, there's nothing to unmount.
• Tasks rarely block. If tasks return instantly, the mount/unmount machinery is pure overhead; a platform-thread pool is simpler and faster.
• You depend on thread-pool semantics for throttling. If your architecture uses "pool of size N" as a back-pressure mechanism, moving to unbounded virtual threads can flood a downstream. Replace the pool with an explicit Semaphore / rate limiter — don't just delete the bound.
• Legacy code pins heavily and you're stuck on JDK ≤ 23 with synchronized you can't change.

Structured concurrency — coordinating the abundance

Virtual threads hand you cheap threads; but when a request splits into ten concurrent subtasks, how do you guarantee they all finish or cancel correctly? That's where structured concurrency comes in.

The core idea: if a task splits into concurrent subtasks, those subtasks must live and die within a lexical scope — like a try block — so that lifetimes form a clean tree instead of a tangle of fire-and-forget futures.

Look more closely at the unstructured ExecutorService/Future world: submit two futures, and if one fails you must remember to cancel the other; if the caller is interrupted, the futures leak (orphaned, holding resources); errors surface via ExecutionException far from the fork. Thread leaks and orphaned work are the default failure mode of that model.

StructuredTaskScope enforces the discipline: all subtasks forked in a scope must finish before the scope closes. If the parent is cancelled, subtasks are cancelled; if a subtask fails, siblings can be cancelled. Errors and cancellation propagate along the task tree, and the whole thing shows up as a coherent tree in the debugger and in thread dumps.

The JDK 21 preview API (most widely deployed today)

// "Invoke all, fail fast": run both calls concurrently; if either throws,
// cancel the other and propagate.
Response handle(long userId, long orderId) throws Exception {
    try (var scope = new StructuredTaskScope.ShutdownOnFailure()) {
        Subtask<User>  user  = scope.fork(() -> findUser(userId));   // one VT each
        Subtask<Order> order = scope.fork(() -> fetchOrder(orderId));

        scope.join()            // wait for BOTH to finish or one to fail
             .throwIfFailed();  // rethrow the first failure, having cancelled the rest

        return new Response(user.get(), order.get()); // safe: both succeeded
    } // close() guarantees no subtask outlives this block
}

Read it step by step: fork runs a subtask on a fresh virtual thread and returns a Subtask (like a Future). join() waits until both finish or one fails. throwIfFailed() rethrows the failure if there was one — and because the policy is ShutdownOnFailure, the first failure cancels the remaining siblings. Only if you reach return are you sure both succeeded, so .get() is safe.

ShutdownOnSuccess is the dual: race several sources and take the first success, cancelling the losers. (Its use: redundant/hedged calls — ask the same data from three servers and take whoever answers first.)

The JDK 25 redesign (JEP 505 — know this exists)

JEP 505 replaced constructors with a static factory StructuredTaskScope.open(...) and moved the completion policy into a pluggable Joiner interface (philosophy: composition over inheritance). ShutdownOnFailure/ShutdownOnSuccess subclassing is gone:

// JDK 25 preview shape — Joiner encodes the policy, join() returns the result.
try (var scope = StructuredTaskScope.open(Joiner.<Response>allSuccessfulOrThrow())) {
    Subtask<User>  user  = scope.fork(() -> findUser(userId));
    Subtask<Order> order = scope.fork(() -> fetchOrder(orderId));
    scope.join(); // throws if any subtask failed; otherwise all are done
    return new Response(user.get(), order.get());
}

The semantics are the same — bounded lifetime, propagated cancellation — but the surface differs, so pin your examples to the JDK you actually target.

Scoped values — the successor to ThreadLocal

Passing context (current user, tenant, request ID) without threading it through every method signature traditionally meant ThreadLocal. But thread-locals have three problems: they are mutable, unbounded in lifetime (easy to forget remove() → leaks), and expensive to inherit into millions of virtual threads.

Scoped values are an immutable, structured alternative: a value is bound for the dynamic extent of a run/call, visible to all callees (methods invoked within that extent) on that thread — and inherited by child subtasks in a StructuredTaskScope — and automatically unbound when the block exits. No mutation, no leaks, cheap inheritance.

final static ScopedValue<User> CURRENT_USER = ScopedValue.newInstance();

void handleRequest(Request req) {
    User u = authenticate(req);
    // Bind for the dynamic scope of this call; auto-unbound on return.
    ScopedValue.where(CURRENT_USER, u).run(() -> processRequest(req));
}

void processRequest(Request req) {
    // No parameter threading, no ThreadLocal.remove() — just read it.
    User u = CURRENT_USER.get();       // the value bound above
    audit(u.id());
}

A subtle point: rebinding is scoped, not mutation. ScopedValue.where(CURRENT_USER, other).run(...) creates a new binding for a nested extent only; the outer binding is untouched. That's exactly what makes it safe — nobody can corrupt someone else's value from a distance.

Virtual threads vs reactive: choosing

Now that you know both worlds, the practical question is: when which?

The honest take: for the classic "handle many blocking requests" workload, virtual threads give you reactive-grade throughput with dramatically simpler code, and they are the new default for new services on JDK 21+. Reactive still wins where you need sophisticated stream composition and first-class backpressure across async boundaries. ("Backpressure" means: when the consumer is slower than the producer, the system throttles itself so the queue doesn't explode.) Frameworks are adapting: Spring Boot 3.2+ can put the whole servlet stack on virtual threads with spring.threads.virtual.enabled=true.

Common pitfalls & gotchas

• Pooling virtual threads — the #1 anti-pattern. Never do it.
• synchronized around blocking I/O on JDK ≤ 23 — silent pinning; migrate to ReentrantLock or upgrade to JDK 24+.
• ThreadLocal as a cache — millions of threads × cached object = OOM (out of memory). Use scoped values for context; keep genuine caches shared.
• Assuming CPU work speeds up — it doesn't; you still need a cores-sized pool.
• Removing thread-pool bounds without adding a Semaphore — you'll DoS your own database/downstream.
• Deleting --enable-preview and expecting StructuredTaskScope to compile — it's still preview through JDK 25; virtual threads themselves are not preview (JDK 21+).
• Expecting timing/latency wins — Loom improves throughput/scalability, not per-request latency. A single blocking call is no faster.

Best practices

• New services on JDK 21+: default to virtual threads for request handling; measure before assuming.
• Use Executors.newVirtualThreadPerTaskExecutor() inside try-with-resources; never a fixed pool.
• Gate scarce downstreams with Semaphore, not with thread-pool size.
• Prefer java.util.concurrent.locks.Lock over synchronized on hot blocking paths (JDK ≤ 23), and enable JFR jdk.VirtualThreadPinned monitoring in every environment.
• Coordinate concurrent subtasks with StructuredTaskScope (accept the preview flag) rather than raw Future juggling; propagate cancellation.
• Migrate context propagation from ThreadLocal to scoped values on JDK 25.

Interview Questions

Now let's gather everything into real interview questions. Read each answer out loud, then try to say it back in your own words.

synchronized void write(OutputStream out, byte[] data) throws IOException {
    out.write(data); // blocking I/O inside synchronized
}

try (var executor = Executors.newVirtualThreadPerTaskExecutor()) {
    List<Future<Row>> futures = new ArrayList<>();
    for (Long id : ids) futures.add(executor.submit(() -> queryDb(id)));
    return futures.stream().map(f -> f.get()).toList(); // <-- ?
}

Senior notes & advanced edge cases

You now have the right mental model. Let's go where Loom actually bites once you push it in production — the things a senior interviewer uses to find out whether you've only read about virtual threads or actually run them under load. None of the chapter's material is repeated here; this is only the deeper layer.

The scheduler under your skin: parallelism vs maxPoolSize

The chapter said carriers are a ForkJoinPool sized to the cores. That's only half the picture. That number is parallelism (the steady state). There is a second number: maxPoolSize, which defaults to 256 (-Djdk.virtualThreadScheduler.maxPoolSize). Why two numbers? Because of a mechanism called compensation.

When a virtual thread parks on something Loom can unmount (socket, sleep, a j.u.c lock), no carrier is blocked and no compensation is needed. But some blocking genuinely holds the carrier; there the JDK temporarily injects an extra carrier into the pool so throughput doesn't die. So in a production thread dump you may legitimately see more carriers than you have cores — that's normal.

Scheduling is cooperative, not preemptive — and that's a trap

Platform threads are scheduled preemptively by the kernel: every few milliseconds you're taken off the CPU whether you like it or not. Virtual threads are not like that. A virtual thread only leaves its carrier at a blocking point (or an explicit Thread.yield()). Until it reaches one, the carrier is its own.

The direct consequence: a CPU-bound virtual thread spinning in a tight loop with no blocking point never unmounts and monopolises that carrier for a long time. Have a few of them and they can seize every carrier, leaving I/O-bound virtual threads that are ready to run stuck in the queue — with zero pinning involved.

// This virtual thread never voluntarily yields → it hogs a carrier
Thread.ofVirtual().start(() -> {
    long x = 0;
    for (long i = 0; i < 50_000_000_000L; i++) x += i * 31; // no I/O, no yield
    sink(x);
});

Not all blocking is equal: socket I/O vs file I/O

A subtle distinction many people miss: network/socket I/O is genuinely implemented as non-blocking and unmounts the virtual thread cleanly. But filesystem file I/O is not inherently non-blocking on most operating systems (you can't hand a disk read to epoll the way you can a socket). So on JDK 21–23, file operations blocked the carrier and the JDK kept the line alive with compensation (an extra carrier) — not by unmounting. Meaning a heavy file workload does not scale the way a socket workload does.

The pinning sources no tutorial mentions

The chapter named synchronized and native frames as the two pinning sources. But in production the danger usually isn't your code — it's third-party libraries that hold synchronized deep on the hot path without you knowing:

• Logging frameworks: synchronous appenders (e.g. classic Logback) block inside synchronized while writing to file/console. A log-heavy app on JDK 21–23 can silently pin all over the place.
• System.out/PrintStream and BufferedOutputStream: their methods are synchronized; logging with System.out.println on a hot path = pinning.
• Old JDBC drivers and some connection pools that hold synchronized + I/O in their internal locking.

ThreadLocal, MDC, and the "named-thread" assumption break

Three old assumptions that fall over with virtual threads:

1. ThreadLocal inheritance is OFF by default. Thread.ofVirtual() does not inherit InheritableThreadLocal values from the parent unless you explicitly ask. Legacy code that relied on "the child sees the parent's context" silently reads null. (The thread builder can even forbid thread-locals entirely with .allowSetThreadLocals(false) to drive per-thread memory to zero.)

2. Logging MDC rides on ThreadLocal. So it still works with virtual threads, but if a framework copied MDC from a thread pool, that copy path no longer makes sense. The modern, correct way to propagate context (user/tenant/traceId) in the Loom world is the scoped values the chapter introduced.

3. A virtual thread is unnamed by default. Any metric or log that keyed off the thread name (worker-7) now sees an empty string. Observability code that "grouped by thread name" must be rewritten.

Observability at a million threads: your tools change

The classic jstack is useless (and slow) for millions of threads. Loom shipped a new thread dump built for exactly this:

# Grouped, machine-readable (JSON) dump that shows the StructuredTaskScope tree
jcmd <pid> Thread.dump_to_file -format=json /tmp/threads.json

This new dump shows virtual threads grouped as a tree of scopes — precisely what makes structured concurrency debuggable. In JFR, know this: jdk.VirtualThreadStart/VirtualThreadEnd are disabled by default because of the sheer volume, but jdk.VirtualThreadPinned and jdk.VirtualThreadSubmitFailed are enabled and are exactly the ones you watch in production.

Backpressure: the pool was also your bouncer

The chapter noted a pool both ran and throttled work. But there's a layer above that too: in the old model, the thread limit was a natural admission control at the edge of the system — when all threads were busy, a new connection waited in the accept queue, which prevented overload. With virtual threads you can accept unbounded connections; that natural bouncer is gone, and in a spike millions of requests arrive at once and blow up memory / the downstream.

Memory & GC: you now count heap, not threads

A parked virtual thread's stack (its continuation) lives on the heap. So a million threads with deep stacks = real pressure on heap and GC. Memory now grows with stack depth × number of live threads, not with a fixed megabyte per thread. Practical result: your profile shifts; instead of "address space for stacks," worry about "heap and GC pauses." A deeply recursive thread, in a million copies, can OOM you in ways platform-thread intuition wouldn't predict.

StructuredTaskScope in the real world: deadlines, partial results, a hand-rolled Joiner

The chapter covered ShutdownOnFailure/ShutdownOnSuccess. Three practical things you'll need in production:

• Deadlines: instead of an unbounded join(), use joinUntil(Instant) so that if the subtasks haven't finished by a deadline, they're all cancelled together. This is the "the whole request must answer within 200ms or fall back" pattern.
• Partial results: sometimes you don't want the first failure to kill everything; you want "collect whatever succeeded and ignore the failures" (e.g. fan-out to 5 sources where 3 successes suffice). In the JDK 25 API this is a custom Joiner (or allUntil(predicate)); in the JDK 21 API you loop over Subtask.state() yourself.
• Cancellation flows downward: cancellation propagates parent→child, but a child cannot cancel its parent. That one-directionality is exactly what keeps the tree safe.

// Whole-request deadline: both subtasks finish by the deadline or all get cancelled
Instant deadline = Instant.now().plusMillis(200);
try (var scope = new StructuredTaskScope.ShutdownOnFailure()) {
    var user  = scope.fork(() -> findUser(id));
    var order = scope.fork(() -> fetchOrder(id));
    scope.joinUntil(deadline);   // not done by the deadline → TimeoutException + cancel all
    scope.throwIfFailed();
    return new Response(user.get(), order.get());
}

Diagram: what happens when a virtual thread blocks?

flowchart TD
  B[Virtual thread blocks] --> Q{Loom-aware unmount possible?}
  Q -- "socket I/O, sleep, j.u.c lock" --> U[Unmount: stack to heap, carrier freed]
  Q -- "no" --> P{Why not?}
  P -- "file I/O, Object.wait pre-24" --> C[Compensate: add carrier up to maxPoolSize 256]
  P -- "synchronized JDK 21-23, or JNI/native" --> PIN[PINNED: carrier held, NO compensation]
  U --> OK[Scales to millions]
  C --> OK2[Scales, but bounded by 256 carriers]
  PIN --> BAD[Throughput collapse, risk of starvation/deadlock]

Senior interview questions (hard)