Java 24 Virtual Threads and Structured Concurrency Guide

By /

Java 24 Virtual Threads: The Concurrency Revolution, Explained Simply

For 25 years, Java developers lived with a painful trade-off: write simple blocking code that wastes threads, or write complex reactive code (Project Reactor, RxJava) that’s hard to debug. Java 24 virtual threads eliminate this trade-off entirely. You write simple blocking code AND it scales to millions of concurrent operations. This isn’t incremental improvement — it’s a fundamental change in how Java handles concurrency.

The Problem Virtual Threads Solve — Explained for Everyone

Imagine a restaurant with 10 waiters (threads). Each waiter takes an order and then stands at the kitchen counter waiting for the food (blocking I/O call). While waiting, that waiter can’t serve other tables. With 10 waiters and 100 tables, 90 tables are unserved.

The reactive programming solution was like training waiters to juggle: take an order, start cooking, immediately move to the next table, come back when cooking is done. This works but makes the waiters’ job incredibly complex — and debugging what went wrong when an order gets lost is a nightmare.

Virtual threads are like having unlimited waiters that cost almost nothing. Each table gets its own waiter. That waiter CAN stand and wait at the kitchen — because having 1000 idle virtual waiters costs almost no resources. The code is simple (each waiter follows a straightforward script), and you can handle any number of tables.

In technical terms: a traditional Java thread maps 1:1 to an OS thread, consuming ~1MB of stack memory each. With 200 threads, you’re using 200MB just for stacks. Virtual threads are managed by the JVM and share a small pool of OS threads — a million virtual threads might use only 200MB total because idle virtual threads consume almost zero resources.

Structured Concurrency: The Other Half of the Revolution

Virtual threads alone solve the scale problem. Structured concurrency (finalized in Java 24 after previewing since Java 19) solves the safety problem: ensuring that concurrent tasks don’t leak, that failures propagate correctly, and that parent tasks wait for all children to complete.

// THE REAL-WORLD PROBLEM: Load a user dashboard
// Need: user profile + recent orders + recommendations
// Requirements: If ANY fetch fails, cancel the others and return an error
// Old way: CompletableFuture — verbose, error-prone, tasks can leak

// Java 24: Structured Concurrency — clean, safe, no leaks possible
public record Dashboard(UserProfile profile, List<Order> orders, List<Product> recs) {}

public Dashboard loadDashboard(String userId) throws Exception {
    try (var scope = new StructuredTaskScope.ShutdownOnFailure()) {

        // Fork three concurrent tasks — each runs on a virtual thread
        Subtask<UserProfile> profile = scope.fork(
            () -> userService.getProfile(userId)     // Blocking call — that's OK!
        );
        Subtask<List<Order>> orders = scope.fork(
            () -> orderService.getRecent(userId, 10)  // Another blocking call
        );
        Subtask<List<Product>> recs = scope.fork(
            () -> recService.getPersonalized(userId)   // And another
        );

        scope.join();            // Wait for ALL tasks
        scope.throwIfFailed();   // If any failed, throw its exception
        // At this point, ALL three tasks succeeded

        return new Dashboard(profile.get(), orders.get(), recs.get());
    }
    // GUARANTEE: When this block exits, all forked tasks are DONE.
    // No leaked threads. No orphaned operations. No race conditions.
}

// COMPARE WITH THE OLD CompletableFuture APPROACH:
public Dashboard loadDashboardOldWay(String userId) {
    CompletableFuture<UserProfile> profileFuture =
        CompletableFuture.supplyAsync(() -> userService.getProfile(userId));
    CompletableFuture<List<Order>> ordersFuture =
        CompletableFuture.supplyAsync(() -> orderService.getRecent(userId, 10));
    CompletableFuture<List<Product>> recsFuture =
        CompletableFuture.supplyAsync(() -> recService.getPersonalized(userId));

    // Problem: If profileFuture fails, ordersFuture and recsFuture keep running
    // Problem: If we return early due to timeout, tasks are orphaned
    // Problem: Exception handling is complex and error-prone
    CompletableFuture.allOf(profileFuture, ordersFuture, recsFuture).join();

    return new Dashboard(profileFuture.join(), ordersFuture.join(), recsFuture.join());
}

The difference isn’t just syntactic. The structured version is provably safe: when the try-with-resources block exits, every forked task is guaranteed to be complete or cancelled. With CompletableFuture, orphaned tasks are a real production issue — they consume threads, hold database connections, and cause subtle memory leaks.

Java 24 virtual threads code development
Structured concurrency guarantees no leaked threads — when the scope closes, everything is done

Scoped Values: Replacing ThreadLocal

ThreadLocal has been Java’s way to pass context (user ID, request trace ID, authentication token) through the call stack without adding parameters to every method. But ThreadLocal has problems with virtual threads: it’s mutable, it can leak, and its lifecycle doesn’t match structured concurrency’s scope model.

ScopedValue is the replacement. It’s immutable, automatically inherited by child tasks, and its lifecycle matches the StructuredTaskScope:

// Define scoped values (typically as static fields)
private static final ScopedValue<String> CURRENT_USER = ScopedValue.newInstance();
private static final ScopedValue<String> TRACE_ID = ScopedValue.newInstance();

// Set values for a scope — automatically available in all child virtual threads
public void handleRequest(HttpRequest request) {
    ScopedValue.where(CURRENT_USER, request.getUserId())
               .where(TRACE_ID, UUID.randomUUID().toString())
               .run(() -> {
                   // Any code called here — including in forked virtual threads —
                   // can access CURRENT_USER.get() and TRACE_ID.get()
                   processOrder(request.getOrderData());
               });
    // Values are automatically cleaned up — no "remember to remove" like ThreadLocal
}

// Deep in the call stack, any method can access the scoped values
public void logActivity(String action) {
    logger.info("User {} performed {} [trace: {}]",
        CURRENT_USER.get(), action, TRACE_ID.get());
}

Java 24 Virtual Threads: Migration from Thread Pools

The migration is straightforward for I/O-bound applications (which is most web services):

Step 1: Replace your thread pool executor with a virtual thread executor:

// BEFORE
ExecutorService executor = Executors.newFixedThreadPool(200);

// AFTER
ExecutorService executor = Executors.newVirtualThreadPerTaskExecutor();
// That's it. Each submitted task gets its own virtual thread.
// No pool sizing, no queue configuration, no tuning.

Step 2: For Spring Boot applications, add one line to application.properties:

spring.threads.virtual.enabled=true

This makes all request-handling threads virtual. Your existing controller code — unchanged — now scales to thousands of concurrent requests instead of being limited to your thread pool size.

Step 3: Remove reactive programming code that you only wrote for scalability (not for streaming). If you adopted WebFlux or Project Reactor solely because thread pools couldn’t handle your concurrency requirements, you can now rewrite those endpoints as simple blocking code with virtual threads.

Thread migration code refactoring
Migration is often as simple as changing one line of thread pool configuration

When NOT to Use Virtual Threads

Virtual threads are not a universal replacement for all threading patterns:

  • CPU-bound computation: Image processing, mathematical simulations, and encryption benefit from a fixed thread pool sized to CPU cores. Virtual threads add no benefit here because the bottleneck is CPU, not I/O waiting.
  • synchronized blocks with I/O: Virtual threads get “pinned” to their carrier thread during synchronized blocks. Use ReentrantLock instead of synchronized if the critical section contains blocking I/O.
  • Native code (JNI): Virtual threads pin during native method calls. If your hot path goes through JNI, profile carefully.

The rule of thumb: if your code spends most of its time waiting (database queries, HTTP calls, file I/O), virtual threads are transformative. If it spends most of its time computing, stick with platform thread pools.

Performance benchmarking dashboard
Virtual threads handle 1M+ concurrent connections with under 1GB heap — impossible with platform threads

Related Reading:

Resources:

In conclusion, Java 24 virtual threads end the 10-year experiment of reactive programming for scalability. You get the simplicity of blocking code with the scalability of reactive systems. For any Java team building I/O-heavy services, this is the most important Java feature since lambdas.

Scroll to Top