Java 21's virtual threads significantly improve the performance of high-concurrent applications. 1. It manages lightweight threads through JVM, making it easy for a stand-alone to run hundreds of thousands of concurrent tasks; 2. It is suitable for I/O-intensive scenarios such as web services, microservices and batch processing; 3. The existing blocking code does not need to be rewrite, it only needs to be run in virtual threads; 4. It is recommended to use StructuredTaskScope to manage concurrent tasks to avoid resource leakage; 5. It is not suitable for CPU-intensive tasks, and platform threads or parallel streams should continue to be used; 6. Mainstream frameworks such as Spring Boot 6, Tomcat, and Jetty are supported, and can be enabled through configuration; 7. Note that blocking calls such as JDBC will occupy the carrier thread and affect the overall concurrency; 8. Avoid pooling virtual threads, abuse of ThreadLocal, and adopt asynchronous logs for optimal performance. Proper use of virtual threads will greatly improve throughput, reduce latency and simplify code.

Java 21's introduction of virtual threads marks a turning point for building high-concurrency applications. Unlike traditional platform threads (which are OS-level and expensive to create), virtual threads are lightweight, managed by the JVM, and make it dramatically easier to scale applications handling thousands or even millions of concurrent tasks—without rewriting your entire codebase.

You don't need to become a concurrency expert overnight, but understanding how to effectively use virtual threads is now essential for modern Java performance.

What Are Virtual Threads and Why They Matter

Virtual threads are part of Project Loom, designed to simplify concurrent programming in Java. Here's the core idea:

• Platform threads (the old way): Each thread maps 1:1 to an OS thread. Creating too many causes high memory usage and context-switching overhead.
• Virtual threads : Many virtual threads run on a small number of underlying platform threads. The JVM handles scheduling and switching efficiently.

? Key benefit : You can now spawn hundreds of thousands of threads without crashing your server.

This is especially useful for:

• I/O-heavy applications (web servers, microservices)
• APIs that call multiple downstream services
• Batch processing with high parallelism

And the best part? Your existing code often works as-is —you just need to run it on a virtual thread.

How to Use Virtual Threads in Practice

Using virtual threads is surprisingly simple. You don't need new frameworks or complex APIs—just use Thread.startVirtualThread() or structured concurrency via StructuredTaskScope .

Option 1: Direct Use with startVirtualThread()

 Thread.startVirtualThread(() -> {
    System.out.println("Running on a virtual thread: " Thread.currentThread());
    // Simulate I/O work
    try { Thread.sleep(1000); } catch (InterruptedException e) {}
    System.out.println("Done");
});

No thread pool needed. Each call spawns a new virtual thread.

Option 2: Using StructuredTaskScope (Recommended)

For managing multiple concurrent tasks safely, StructuredTaskScope ensures all child tasks complete (or fail) together, with proper cancellation and error handling.

 try (var scope = new StructuredTaskScope.ShutdownOnFailure()) {
    var subtask1 = scope.fork(() -> fetchUser(1));
    var subtask2 = scope.fork(() -> fetchOrder(1));

    scope.join(); // Wait for all tasks
    scope.throwIfFailed(); // Propagate any failure

    User user = subtask1.get();
    Order order = subtask2.get();
}

? This replaces messy CompletableFuture chains and avoids resource leaks.

When to Use Virtual Threads (and When Not To)

Not every workload benefits from virtual threads. Know the sweet spot:

? Use virtual threads when:

• Tasks spend time waiting (I/O, network calls, database queries)
• You have high parallelism needs (eg, handling 10K HTTP requests)
• You're using blocking code (like traditional InputStream , JDBC, etc.)

? Avoid for CPU-intensive work:

• Number crunching
• Image/video processing
• Heavy computings

Why? Virtual threads don't reduce CPU load. For CPU-bound tasks, stick to parallel streams or fixed-size thread pools like ForkJoinPool .

? Rule of thumb: If your thread is mostly waiting , virtual threads win. If it's busy , stick to platform threads.

Integrating with Existing Frameworks

You don't need to wait for frameworks to "support" virtual threads—many already work seamlessly.

Spring Boot (6)

Enable virtual threads in application.properties :

 server.tomcat.threads.virtual.enabled=true

Or customize the executor:

 @Bean
public TaskExecutor virtualThreadExecutor() {
    var factory = Executors.newThreadPerTaskExecutor(Thread.ofVirtual().factory());
    return new ConcurrentTaskExecutor(Executors.newThreadPerTaskExecutor(
        Thread.ofVirtual().factory()
    ));
}

Tomcat, Jetty, Netty

Recent versions support virtual threads as the request-handling mechanism. When enabled, each HTTP request runs on its own virtual thread—no more thread pool bottlenecks.

JDBC Warning

Most JDBC drivers are blocking and synchronous , which can tie up carrier threads. While virtual threads help, true async DB access (like R2DBC) is better for maximum throughput.

?? Long-blocking calls (eg, slow JDBC queries) still reduce overall concurrency because they occur the underlying platform thread ("carrier thread").

Performance Tips and Pitfalls

Here's what to watch for:

• Don't pool virtual threads : They're cheap to create. Use newThreadPerTaskExecutor , not fixed thread pools.
• Avoid thread-local abuse : Virtual threads can create millions of instances—storing large objects in ThreadLocal can cause memory issues.
• Monitor carrier threads : The JVM uses a fixed pool of platform threads to run virtual ones. If all are blocked (eg, by slow JDBC), your app stalls.
• Use async logging : If your logging framework blocks I/O, it defeats the purpose. Consider async appenders.

Bottom Line

Java 21's virtual threads aren't just a performance tweak—they're a paradigm shift in how we write concurrent applications.

You can now:

• Write simple, readable, blocking-style code
• Handle massive concurrency with minimal hardware
• Reduce reform on complex reactive frameworks (like Reactor or RxJava) unless you need backpressure

Start by running your existing blocking I/O tasks on virtual threads. Measure the difference. You'll likely see higher throughput, lower latency, and simpler code .

Basically, if you're building server-side Java applications in 2024 and not using virtual threads, you're leaving performance and developer productivity on the table.

The above is the detailed content of Mastering Java 21 Virtual Threads for High-Concurrency Applications. For more information, please follow other related articles on the PHP Chinese website!