Java Threads, Virtual Threads, Executors and Scoped Values (1Z0-831)

A Java thread is created by handing a task (usually a Runnable) to a Thread object and calling start(); Java SE 25 offers two kinds of thread, platform threads (a thin wrapper around an operating-system thread) and virtual threads (lightweight threads managed by the JVM and mounted on a small pool of carrier platform threads while they run). Both are instances of java.lang.Thread, and isVirtual() tells them apart.

Thread.ofPlatform() and Thread.ofVirtual() return a Thread.Builder. A builder can be configured once and reused: name("job-") gives every thread the same name, while name("job-", 1) appends a counter that starts at 1 and increases with each thread the builder creates (job-1, job-2…). factory() turns a builder into a ThreadFactory for an executor. The platform builder also has daemon(boolean) and priority(int); the virtual builder does not, because those properties are fixed for virtual threads.

Default names and daemon status

A platform thread made with new Thread(...) gets a default name of the form Thread-N. A virtual thread gets no default name: getName() returns the empty string unless a builder named it. A platform thread built without daemon(...) inherits the daemon status of the thread that created it, and main is a non-daemon thread, so it is normally false. The thread that runs main is itself a platform thread, so Thread.currentThread().isVirtual() in main returns false. Virtual threads are always daemons.

public class Main {
    public static void main(String[] args) throws Exception {
        Thread.Builder b = Thread.ofPlatform()
            .name("io-", 3).daemon(true).priority(7);
        Thread p = b.start(() -> {
            Thread me = Thread.currentThread();
            System.out.println(me.getName() + " "
                + me.isDaemon() + " " + me.getPriority());
        });
        p.join();
        Thread v = Thread.ofVirtual().name("vt").start(() -> {
            Thread me = Thread.currentThread();
            System.out.println(me.getName() + " "
                + me.isDaemon() + " " + me.getPriority());
        });
        v.join();
        System.out.println(b.unstarted(() -> { }).getName());
    }
}

This prints io-3 true 7, then vt true 5, then io-4: the platform builder's daemon and priority settings reach its thread, the virtual thread is a daemon at priority 5 regardless, and the builder's counter has moved on because it already created io-3.

Virtual threads exist to make blocking code cheap: when a virtual thread blocks on I/O, a sleep or a lock wait, the JVM unmounts it from its carrier thread and the carrier runs another virtual thread. That is why an application can have millions of them. They do not make computation faster; CPU-bound work still runs on the same number of cores, and a virtual thread is scheduled onto a small set of carrier platform threads.

Two of these rules show up as runtime behaviour rather than compile errors. setDaemon(boolean) is declared on Thread, so virtualThread.setDaemon(false) compiles, but it throws IllegalArgumentException (message 'false' not legal for virtual threads). setPriority(Thread.MAX_PRIORITY) on a virtual thread is silently ignored: getPriority() still returns 5.

On a platform thread, daemon status must be chosen before start(): calling setDaemon(...) while the thread is alive throws IllegalThreadStateException (a different exception from the virtual-thread IllegalArgumentException). Once the thread has terminated the call no longer throws, but it is pointless by then.

Because virtual threads are daemons, the JVM does not wait for them when main ends. Code that must see a virtual thread's work has to wait for it explicitly, with join(), a Future, or by closing the executor that runs it.

Because they are not pooled, the virtual-thread-per-task executor creates a new thread for every submission, so two tasks never see the same Thread object. A newSingleThreadExecutor(), by contrast, keeps one platform worker alive and runs every task on it.

start() creates a new thread of execution and calls the task's run() on it; calling run() yourself is an ordinary method call that runs the task on the current thread. With t.run(), Thread.currentThread() inside the task returns the caller (for example main), and whatever name was set on t is never seen.

A thread's state is reported by getState() as a Thread.State value:

The lifecycle only moves forward: a thread never returns to NEW. A Thread object can be started once; calling start() again, even after it has terminated, throws the unchecked IllegalThreadStateException. To run the task again, create a new thread.

join and join with a timeout

t.join() blocks the caller until t terminates; while it waits, the caller is WAITING. t.join(200) waits at most 200 ms and then simply returns: it does not throw anything when the time runs out. Afterwards t.isAlive() tells you whether t actually finished. A thread still inside Thread.sleep(3_000) at that moment is alive and TIMED_WAITING. Both forms of join (and sleep) throw the checked InterruptedException, so the caller must catch or declare it.

BLOCKED is specific to monitor contention (synchronized); a sleeping thread is never BLOCKED. Locking itself belongs to objective 8.2.

Interruption is a cooperative request to stop: t.interrupt() sets t's interrupt status flag and, if t is blocked in sleep, join or wait, wakes it with an InterruptedException. It never kills the thread; the thread's own code decides what to do.

• Throwing clears the flag. When a blocking method throws InterruptedException, it clears the interrupt status first, so isInterrupted() inside the catch block returns false. Code that wants callers to know about the interrupt calls Thread.currentThread().interrupt() again in the handler.
• A pending interrupt is honoured on entry. If the flag is already set when sleep is called, it throws immediately without sleeping. So it does not matter whether interrupt() lands just before or during the sleep: the result is the same exception.
• Running code is not stopped. A loop that never blocks and never checks the flag ignores interrupt() completely.

public class Main {
    public static void main(String[] args) throws Exception {
        Thread w = new Thread(() -> {
            Thread me = Thread.currentThread();
            try {
                Thread.sleep(10_000);
                System.out.print("woke ");
            } catch (InterruptedException e) {
                System.out.print(me.isInterrupted() + " ");
                me.interrupt();
                System.out.print(me.isInterrupted() + " ");
            }
        });
        w.start();
        w.interrupt();
        w.join();
        System.out.println(w.getState());
    }
}

It prints false true TERMINATED: main's interrupt() wakes the sleeping worker, the throw has already cleared the flag, and re-interrupting in the handler sets it again so code further up the worker's call chain can see it. If the interrupt lands before the worker reaches sleep, the pending flag makes sleep throw at once, so the output is the same.

Executors use the same mechanism: shutdownNow() and Future.cancel(true) try to stop a running task by interrupting the worker that runs it.

Runnable and Callable<V> are the two task types: Runnable.run() returns nothing and cannot throw checked exceptions, while Callable.call() returns a V and is declared throws Exception.

Which interface a lambda becomes

ExecutorService.submit is overloaded for both types, and the lambda body decides which applies:

• A body that returns a value (() -> "B" or a block with return 1;) fits only Callable, so a checked exception such as the InterruptedException from Thread.sleep needs no handler.
• A void body (() -> System.out.print("x"), or a block with no return) fits only Runnable, so a checked exception inside it must be caught or the code does not compile (unreported exception InterruptedException).
• An expression that is both a valid statement and a value, such as count++ or a method call that returns something, fits both. Overload resolution then prefers the value-returning Callable, so submit(() -> count++) returns a future holding the value before the increment.
• execute(Runnable) has no Callable overload: passing a value-returning block to it fails to compile (bad return type in lambda expression). A Callable lambda must return a value on every path (missing return value otherwise).

Reading results and failures

Future.get() blocks until the task completes. If the task threw, get() throws a checked ExecutionException whose getCause() is the original exception; the exception never escapes on the caller's thread by itself. get(timeout, unit) throws TimeoutException if the result is not ready in time. isDone() reports completion without blocking, and cancel(boolean) attempts to cancel (with true, interrupting a running task).

import java.io.IOException;
import java.util.concurrent.*;

public class Main {
    public static void main(String[] args) throws Exception {
        try (var es = Executors.newSingleThreadExecutor()) {
            Future<String> slow = es.submit(() -> {
                Thread.sleep(500);
                return "late";
            });
            try {
                slow.get(50, TimeUnit.MILLISECONDS);
            } catch (TimeoutException e) {
                System.out.print("timeout ");
            }
            System.out.print(slow.get() + " ");
            Future<String> io = es.submit(() -> {
                throw new IOException("disk");
            });
            try {
                io.get();
            } catch (ExecutionException e) {
                System.out.println(e.getCause().getMessage()
                    + " " + io.isDone());
            }
        }
    }
}

Output: timeout late disk true. The timed get gave up after 50 ms without cancelling the task, so the later plain get() still returned its value. A block that only throws can complete as neither a void nor a value body, so it fits both overloads and Callable is chosen; the checked IOException therefore needs no handler and arrives as the cause of the ExecutionException.

An ExecutorService runs submitted tasks on threads it manages, so code describes what to run and the executor decides where. The Executors factory methods cover the common shapes:

execute(Runnable) (from the Executor interface) is fire-and-forget; submit(...) returns a Future. Only a single-thread executor guarantees the order in which tasks print; with a pool of several workers, output order between tasks is not predictable unless something (a Future.get(), a latch, a join) forces it.

invokeAll and invokeAny

• invokeAll(tasks) runs every Callable in the collection, blocks until all are done, and returns a List<Future<T>> in the same order as the task list, not in completion order. A failed task's future throws ExecutionException from get(). With a timeout (invokeAll(tasks, 100, MILLISECONDS)), unfinished tasks are cancelled when it expires, and their futures report isCancelled().
• invokeAny(tasks) returns the result of one task that completed successfully (and cancels the rest). Failures are tolerated as long as one task succeeds; only if every task fails does it throw ExecutionException. With a timeout it throws TimeoutException if no task succeeds in time.

import java.util.*;
import java.util.concurrent.*;

public class Main {
    public static void main(String[] args) throws Exception {
        List<Callable<Integer>> tasks = List.of(
            () -> { Thread.sleep(150); return 1; },
            () -> Integer.parseInt("two"),
            () -> 3);
        try (var es = Executors.newFixedThreadPool(3)) {
            for (Future<Integer> f : es.invokeAll(tasks)) {
                try {
                    System.out.print(f.get() + " ");
                } catch (ExecutionException e) {
                    System.out.print("x ");
                }
            }
            try {
                es.invokeAny(List.of(tasks.get(1), tasks.get(1)));
            } catch (ExecutionException e) {
                System.out.println("none succeeded");
            }
        }
    }
}

It prints 1 x 3 none succeeded: the futures follow the list order even though the first task finished last, the failing task's future throws ExecutionException from get(), and invokeAny throws ExecutionException because no task succeeded.

An executor keeps its platform worker threads alive until it is shut down, so a program that uses a fixed or single-thread pool and never shuts it down (or closes it) does not exit. Always shut down or close an executor when its work is done.

• After either shutdown method, isShutdown() is true and any new execute or submit is rejected: the default policy throws the unchecked RejectedExecutionException to the caller (not IllegalStateException).
• isTerminated() becomes true only once shutdown has been requested and every task has finished.
• shutdownNow() attempts to stop the running task, and the Executors pools do so by interrupting it; whether that task stops depends on its code (a sleeping task gets InterruptedException). The tasks still waiting in the queue never start; the returned list holds them.

ExecutorService is AutoCloseable

Since Java 19, ExecutorService extends AutoCloseable. close() performs an orderly shutdown and then waits for all submitted tasks to finish, so a try-with-resources block over an executor guarantees the tasks have completed before the statement after the block runs. This applies to the virtual-thread executor too: the wait comes from close(), not from the daemon status of its threads. The resource can be declared in the header or, since Java 9, be an effectively final variable: try (es) { ... }.

import java.util.concurrent.*;

public class Main {
    public static void main(String[] args) throws Exception {
        ExecutorService es = Executors.newSingleThreadExecutor();
        es.submit(() -> {
            try {
                Thread.sleep(300);
            } catch (InterruptedException e) { }
            System.out.print("job ");
        });
        es.shutdown();
        var ms = TimeUnit.MILLISECONDS;
        System.out.print(es.awaitTermination(50, ms) + " ");
        System.out.println(es.awaitTermination(2_000, ms)
            + " " + es.isTerminated());
    }
}

It prints false job true true: shutdown() returned at once, the first awaitTermination timed out with false while the job was still sleeping, and the second returned true once it had finished. A try-with-resources block over the executor would do the same waiting through close().

A ScheduledExecutorService runs tasks after a delay or repeatedly, and every scheduling method returns a ScheduledFuture straight away without waiting for the task.

• schedule(Runnable, delay, unit) returns a ScheduledFuture<?> whose get() yields null.
• schedule(Callable<V>, delay, unit) returns a ScheduledFuture<V>; isDone() is false until the delay passes and the task runs, and get() blocks until then and returns the value.
• scheduleAtFixedRate(task, initialDelay, period, unit) and scheduleWithFixedDelay(task, initialDelay, delay, unit) take only a Runnable.

So a task that takes about 1 second, scheduled with a 4-second interval, starts about every 4 seconds at a fixed rate and about every 5 seconds with a fixed delay. When a run outlasts the interval, a fixed rate starts the next run as soon as the previous one ends, while a fixed delay still adds the whole delay after it. A periodic task never runs concurrently with itself, regardless of how many threads the pool has.

When a periodic task fails

A periodic task runs until the executor shuts down or the future is cancelled, so its future normally never completes and get() blocks indefinitely. If one run throws, the schedule is ended: later runs are suppressed and the future completes exceptionally, so get() throws ExecutionException with the thrown exception as its cause. Catch exceptions inside a periodic task if it must keep running.

CompletableFuture is a Future that can be completed and chained: supplyAsync(supplier) (or runAsync(runnable)) starts work on the common ForkJoinPool or a given executor, and each then... method returns a new stage that runs when the previous one completes.

When a stage throws, it completes exceptionally and every dependent thenApply/thenCompose/thenCombine stage is skipped and completes with the same failure. Only exceptionally and handle turn a failure back into a value. In handle, the arguments are (result, null) on success and (null, exception) on failure.

get versus join

Both block for the result, but they wrap a failure differently. get() throws the checked ExecutionException (and declares InterruptedException); join() throws the unchecked CompletionException. Either way, getCause() is the original exception, for example ArithmeticException. The exception passed to exceptionally, handle or whenComplete is also usually wrapped: any stage whose failure came from an exception thrown in an async or dependent task (even one attached directly to supplyAsync) receives a CompletionException. Only a future failed explicitly with completeExceptionally(ex) passes ex unwrapped.

import java.util.concurrent.*;

public class Main {
    public static void main(String[] args) {
        var price = CompletableFuture.supplyAsync(() -> 20);
        var qty = CompletableFuture.supplyAsync(() -> 3);
        System.out.println(price.thenCombine(qty, (p, q) -> p * q)
            .thenApply(t -> t + 1)
            .join());

        var failed = CompletableFuture
            .supplyAsync(() -> Integer.parseInt("x"))
            .thenApply(n -> n * 2);
        System.out.println(
            failed.handle((v, e) -> e == null ? v : -1).join());
        var seen = failed.whenComplete((v, e) -> System.out.println(
            "saw " + e.getClass().getSimpleName()));
        System.out.println(seen.isCompletedExceptionally());
    }
}

It prints 61, -1, saw CompletionException and true: the n * 2 stage never ran, handle turned the failure into -1, and whenComplete saw the (wrapped) failure while its own stage still completed exceptionally.

A scoped value (java.lang.ScopedValue, final in Java SE 25) is a one-way, immutable channel for passing context, such as the current user or tenant, to code deep in a call chain without adding a parameter to every method. A value is bound for a dynamic extent, the time a particular run or call executes on that thread, and is readable by anything that code calls.

• Declare it, usually as a static final field: static final ScopedValue<String> USER = ScopedValue.newInstance();
• Bind it with ScopedValue.where(USER, "ana"), which returns a ScopedValue.Carrier. Chain further .where(ID, 7) calls to bind several values at once.
• Run code with the bindings: carrier.run(runnable) returns nothing; carrier.call(op) returns the operation's result (and may throw the operation's checked exception).
• Read it with get(), which throws NoSuchElementException (message ScopedValue not bound) when there is no binding. isBound() tests first; orElse(other) returns a fallback when unbound (the fallback may not be null: orElse(null) throws NullPointerException); orElseThrow(supplier) throws an exception of your choice.

The binding ends when run or call returns. Whether a value is bound depends only on whether the reading code is currently executing inside such a call, never on which object or method does the reading: code run before the call, after it, or by any other route sees the value as unbound.

Immutable, but can be rebound in a nested scope

There is no set method. Code inside a binding can only start a nested binding with another where(...).run(...); inner code sees the new value, and when the inner run returns the outer value is visible again. Rebinding never throws.

public class Main {
    static final ScopedValue<String> REGION =
        ScopedValue.newInstance();
    static final ScopedValue<Integer> LIMIT =
        ScopedValue.newInstance();

    static String describe() {
        return REGION.get() + ":" + LIMIT.get();
    }

    public static void main(String[] args) throws Exception {
        String r = ScopedValue.where(REGION, "eu")
            .where(LIMIT, 3)
            .call(() -> {
                String inner = ScopedValue.where(LIMIT, 9)
                    .call(Main::describe);
                return inner + " " + describe();
            });
        System.out.println(r);
    }
}

It prints eu:9 eu:3: the nested call rebinds only LIMIT, REGION stays visible from the outer binding, and LIMIT is 3 again once the inner call returns.

Bindings belong to one thread

Bindings are not inherited by threads created with the Thread API or by tasks handed to an ordinary executor, whether the new thread is platform or virtual. A new thread starts with no binding at all, exactly like code outside any run, and creating it does not disturb the creating thread's binding. (Automatic inheritance exists only for subtasks of StructuredTaskScope, which is still a preview API in Java SE 25.)