Java developers have been writing reactive code for years to solve a concurrency problem that the platform itself could never handle well. That might finally be changing. With Java 21 and Project Loom, Virtual Threads bring lightweight concurrency natively to the JVM — and the question is no longer whether reactive works. It does. The real question is whether it should still be the default choice.

The Problem

Platform Threads and Their Limits

Traditional Java threads — known as platform threads — are mapped 1:1 to OS kernel threads. This design is simple but fundamentally limited at scale:

• Limited scalability — you can realistically create only a few thousand threads before the system buckles
• High memory overhead — each thread consumes ~1 MB of stack memory
• Expensive context switching — the OS must save and restore thread state on every switch
• Thread starvation on I/O waits — a thread blocked on a database response is completely idle but still consumes resources

The 1:1 mapping means your application's concurrency ceiling is directly tied to the OS's ability to manage threads — and that ceiling is surprisingly low.

Thread Exhaustion in Production

In a typical I/O-heavy application:

• 10,000 concurrent users each trigger a database query
• Each query blocks its thread while waiting for a response
• The result: 10,000 threads parked and doing nothing, consuming gigabytes of memory
• Context switching overhead destroys throughput
• The system slows to a crawl or crashes entirely

This is the thread exhaustion problem — and it's exactly what drove the industry toward reactive programming.

The Reactive Price

Reactive programming solved the scalability problem by using fewer threads, non-blocking I/O, and async pipelines. Frameworks like Spring WebFlux and Project Reactor became the standard answer. But that solution came with a real bill.

Complex Callback Chains

What should be simple sequential logic — get a user, get their orders, compute a total — turns into a pipeline of nested operators:

The code may be efficient, but it is rarely easy to follow. Business logic gets buried inside flatMap chains and lambda expressions.

Debugging Nightmares

When something goes wrong, the stack trace is almost useless:

Your actual business code is absent. You're hunting for a bug that could be anywhere in the reactive pipeline.

Testing Is No Longer Straightforward

Testing reactive code requires a different mental model and dedicated tooling. A simple assertion becomes a full subscription lifecycle:

Every test requires StepVerifier, explicit subscription management, and careful handling of the async timeline. That cost accumulates across a codebase — in maintenance, onboarding, debugging, and refactoring.

Enter Virtual Threads

What Project Loom Brings

Project Loom introduces Virtual Threads: lightweight threads managed entirely by the JVM, not the OS. Previewed in Java 19 and production-ready since Java 21, they fundamentally change the cost model of concurrency.

A Virtual Thread still looks like a thread to the developer. You create it, start it, and block inside it the same way. The difference is in how the runtime schedules it.

How Parking Works

When a Virtual Thread performs a blocking operation, the JVM parks it and frees the underlying carrier thread to handle other work. When the operation completes, the Virtual Thread is resumed — transparently, without any callback or operator.

This is the key insight: in the old model, blocking was expensive because it tied up an OS thread. In the Virtual Thread model, blocking is cheap because the JVM decouples the logical unit of work from the physical thread running it.

Key Benefits

Creating Virtual Threads

No new paradigm. No operators to memorize. Just Java.

Reactive vs Virtual Threads: The Code Difference

The simplicity gap becomes obvious when comparing equivalent code side by side.

Reactive Style

Virtual Threads Style

The Virtual Threads version reads like pseudocode. It's sequential, readable, and requires zero mental overhead to understand. Both handle I/O efficiently — the Virtual Threads version just does it without asking anything extra from the developer.

Benchmarking: What the Numbers Say

Performance is where the conversation gets nuanced. Three independent benchmark studies provide a clear picture.

Study 1 — JDBC + Hibernate Workload

• Setup: HikariCP connection pool (size: 10), JDBC + Hibernate
• Result: Virtual Threads clearly outperformed platform threads; Reactor remained competitive but required migrating to R2DBC
• Source: github.com/TNG/java-virtual-thread-benchmark

Study 2 — High-End Hardware, Multiple Scenarios

• Setup: Intel Core i5-14600K (5.3 GHz, 12 cores), 64 GB RAM, Ubuntu 24.04, Amazon Corretto JDK 25, Spring Boot 3.5.5
• Scenarios: High user concurrency, PostgreSQL calls, spike tests, smoke tests
• Result: Virtual Threads won 45% of scenarios, Reactor 30%, tied 25%; Virtual Threads had best latency percentiles under high concurrency
• Source: github.com/chrisgleissner/loom-webflux-benchmarks

Study 3 — Constrained Cloud Environment

• Setup: AWS t3.micro (2 vCPU, 1 GiB RAM), Amazon Linux 2023, Java 21, Spring Boot 3.2.0, PostgreSQL (~1,800 records)
• Load: 100–400 concurrent users, repeated iterations
• DB Drivers: R2DBC for WebFlux, JDBC for Virtual Threads
• Result: WebFlux had slightly higher throughput in most scenarios; Virtual Threads delivered comparable latency with significantly simpler code
• Source: vincenzoracca.com/en/blog/framework/spring/virtual-threads-vs-webflux

What the Benchmarks Really Say

The benchmark story is not "Virtual Threads always win." The real takeaway is:

• Virtual Threads are dramatically better than old platform-thread-per-request designs for I/O-heavy workloads
• Reactive still performs very well in many scenarios
• The performance gap between the two is often smaller than the complexity gap

For most teams, that changes the default choice.

Choosing the Right Tool

When Reactive Still Shines

• Fine-grained backpressure control is needed
• Event streaming systems — Kafka consumers, WebSockets, real-time pipelines
• Complex async fan-out/fan-in patterns across microservices
• Systems where strict resource limits must be enforced

When Virtual Threads Are the Better Choice

• I/O-bound workloads — database calls, HTTP requests, file reads
• High concurrency scenarios — thousands to millions of simultaneous requests
• Business logic with lots of blocking calls
• Applications where maintainability and readability matter

Key Insights

The most important thing Project Loom does is not just improve performance — it restores developer ergonomics without sacrificing scalability.

For years, teams accepted reactive complexity because the alternative was poor scalability with platform threads. Now there is a third path: keep the simple, synchronous programming model and still handle high concurrency efficiently.

Reactive is not dead. But it is no longer the forced default for every concurrency problem in Java. That is a healthier place for the ecosystem.

Conclusion

Building scalable Java applications no longer requires adopting a completely different programming model. Virtual Threads give you the performance of async with the simplicity of sync — and for a large class of applications, that is the right trade-off.

If your system is mostly I/O-bound and your goal is software that is both scalable and maintainable, Virtual Threads are now the better default.

Not because reactive failed. But because Java finally learned how to make simple code concurrent again.

Resources

Project Loom (Virtual Threads)

• Official Project Page
• JEP 444 — Virtual Threads Specification
• Oracle Java 21 Documentation

Spring WebFlux & Reactive

• Spring WebFlux Framework
• Project Reactor

Benchmarks

• github.com/TNG/java-virtual-thread-benchmark
• github.com/chrisgleissner/loom-webflux-benchmarks
• vincenzoracca.com — Virtual Threads vs WebFlux

JVM User Space          OS Kernel Space
──────────────────      ──────────────────
Java Thread 1   ──────► Kernel Thread 1
Java Thread 2   ──────► Kernel Thread 2
Java Thread 3   ──────► Kernel Thread 3
Java Thread 4   ──────► Kernel Thread 4
Java Thread 5   ──────► Kernel Thread 5

public Mono<OrderSummary> getUserOrderSummary(String userId) {
    return userRepository.findById(userId)
        .switchIfEmpty(Mono.error(new UserNotFoundException()))
        .flatMap(user -> orderRepository.findAllByUserId(user.getId())
            .map(Order::getPrice)
            .reduce(BigDecimal.ZERO, BigDecimal::add)
            .map(total -> new OrderSummary(user, total))
        );
}

java.lang.NullPointerException: null
    at reactor.core.publisher.FluxMap$MapSubscriber.onNext(FluxMap.java:106)
    at reactor.core.publisher.FluxFlatMap$FlatMapMain.tryEmitScalar(FluxFlatMap.java:488)
    at reactor.core.publisher.FluxFlatMap$FlatMapMain.onNext(FluxFlatMap.java:421)
    at reactor.core.publisher.FluxMapFuseable$MapFuseableSubscriber.onNext(FluxMapFuseable.java:127)
    ... 40k more lines of Reactor internal classes ...
    at java.base/java.lang.Thread.run(Thread.java:833)

@Test
void testOrderSummaryFlow() {
    when(userRepo.findById("u1")).thenReturn(Mono.just(new User("u1", "user1")));
    when(orderRepo.findAllByUserId("u1")).thenReturn(Flux.just(
        new Order(10.0), new Order(20.0)
    ));

    StepVerifier.create(service.getUserOrderSummary("u1"))
        .expectSubscription()           // Ensure stream starts
        .assertNext(summary -> {
            assertEquals("user1", summary.getUserName());
            assertEquals(30.0, summary.getTotal().doubleValue());
        })
        .expectComplete()               // Ensure stream closes successfully
        .verify();                      // ACTUAL TRIGGER: starts the test
}

┌───────┐ ┌───────┐ ┌───────-┐   ┌───────┐ ┌───────┐
│  VT 1 │ │  VT 2 │ │  VT 3  │   │  VT 4 │ │  VT 5 │
└───┬───┘ └───┬───┘ └───-┬───┘   └───┬───┘ └───┬───┘
    └─────────┴────┬─────┘           └────┬────┘
                   │                      │
              ┌────┴─────┐          ┌─────┴────┐
              │   PT 1   │          │   PT 2   │
              └────┬─────┘          └─────┬────┘
                   ↕                      ↕
           ┌───────────────┐    ┌───────────────┐
           │Kernel Thread 1│    │Kernel Thread 2│
           └───────────────┘    └───────────────┘

// Option 1: Direct Thread API
Thread vt = Thread.ofVirtual().start(() -> {
    System.out.println("Running on virtual thread");
});

// Option 2: ExecutorService (recommended for production)
ExecutorService executor = Executors.newVirtualThreadPerTaskExecutor();
executor.submit(() -> processRequest());

userClient.getUser(id)
    .flatMap(user ->
        orderClient.getOrders(user))
    .map(orders ->
        transform(orders))
    .subscribe(...);

var user   = userClient.getUser(id);
var orders = orderClient.getOrders(user);
return transform(orders);