Why Java’s Blocking Model Is a Bottleneck and How Virtual Threads Solve It

1 Synchronous Blocking Design

1.1 Thread Diagram

A typical enterprise request involves three steps: fetching data from a database, fetching data from a web service, and merging the results to send back to the user.

In a servlet container such as Tomcat, a platform thread handles the request and sequentially calls FetchDataFromDB , FetchDataFromService , and SendDataToUser . The CPU‑bound portion (green) is short, while the I/O‑wait portion (red) dominates, causing the thread to sit idle.

1.2 Evaluation

Each platform thread consumes about 1 MB of stack memory, limiting the number of concurrent threads. The usual remedy is a thread pool with vertical (more resources per VM) or horizontal (more instances) scaling.

2 Asynchronous Blocking Design

2.1 Thread Diagram

To improve performance, the database and web‑service calls can run in parallel on separate threads, each submitted to an ExecutorService as Callable or Runnable and coordinated with Future s.

2.2 Evaluation

Parallel I/O reduces overall latency, but the number of platform threads temporarily rises from 1 to 3, worsening scalability during the burst.

3 Reactive‑Style Design

3.1 Partial Reactive Diagram

Since platform threads block during I/O, Servlet 3.0/3.1 introduced non‑blocking request handling. Java 8’s CompletableFuture lets developers define a reactive pipeline: the request thread creates the pipeline and returns to the pool, while the pipeline executes the I/O tasks.

The pipeline runs three activities in parallel (fetch from DB, fetch from service) and then sends the result to the user, freeing the original thread.

Evaluation

Although the pipeline reduces thread blockage, the underlying I/O tasks still occupy platform threads, so developers must ensure those tasks are non‑blocking—a difficult manual guarantee.

4 Fully Reactive Design

To eliminate blocking completely, Java’s NIO (New I/O) provides non‑blocking APIs for sockets, files, and locks. Using these APIs or NIO‑compatible libraries, both database and web‑service calls can execute without holding platform threads.

In this model, only the CPU‑bound portions occupy platform threads; the I/O‑bound portions run on separate threads, achieving true non‑blocking behavior. Spring Boot’s WebFlux (built on Project Reactor) offers a complete stack for such development.

5 Virtual Threads

Java 21 introduces lightweight virtual threads that act as carriers for CPU work while releasing the underlying platform thread during blocking I/O. The JVM automatically switches to non‑blocking implementations of core I/O classes, so a virtual thread never blocks a platform thread.

How the JVM Detects I/O

When a virtual thread reaches an I/O operation, the JVM uses the non‑blocking version of the API; the carrier platform thread is released and later re‑assigned when data becomes available.

Virtual‑Thread Synchronous Diagram

In the original synchronous flow, the request thread is now a virtual thread (blue). Its I/O waits no longer consume a platform thread, providing the same scalability benefits as a reactive pipeline without its complexity.

6 Virtual Threads with Asynchronous Design

6.1 Virtual Threads in Async Blocking

Java 21 also adds StructuredTaskScope and Subtask for structured concurrency, allowing developers to combine virtual threads with asynchronous tasks more cleanly than with raw Future s.

Virtual Threads vs Reactive Frameworks

Maintain imperative coding style

Avoid building complex reactive pipelines

No need to use non‑blocking I/O directly

Easier to code, debug, and understand

7 Summary

With virtual threads in Java 21, blocking I/O no longer ties up platform threads. Developers can achieve high scalability either by using virtual threads together with Java Futures or with the preview Structured Concurrency APIs, without the overhead of full reactive frameworks.