Project Loom introduces virtual threads to solve Java’s concurrency limitations by enabling lightweight, scalable threading. 1. Virtual threads are JVM-managed, low-footprint threads that allow millions of concurrent threads with minimal OS resources. 2. They simplify high-concurrency programming by allowing one thread per request without complex async code. 3. Blocking operations like I/O suspend virtual threads without blocking OS threads, improving throughput. 4. Existing code can adopt virtual threads by replacing traditional thread pools with Executors.newVirtualThreadPerTaskExecutor(). 5. Virtual threads are ideal for I/O-bound tasks like web servers but not for CPU-intensive work. 6. No major code changes are needed, ensuring backward compatibility. As of Java 21, virtual threads are production-ready, offering a simpler, scalable alternative to reactive models while maintaining familiar blocking-style code.

Java’s traditional threading model, based on one-to-one mapping between Java threads and OS threads, has long been a bottleneck for building highly concurrent applications. Each thread consumes significant memory and OS resources, making it impractical to create millions of threads. Project Loom aims to solve this by introducing lightweight concurrency through virtual threads—a major shift in how Java handles concurrency.

The goal? Make it easy to write simple, scalable, and high-throughput concurrent applications without resorting to complex reactive or async programming models.

What Are Virtual Threads?

Virtual threads are lightweight threads managed by the JVM, not the operating system. Unlike platform threads (the traditional java.lang.Thread), thousands or even millions of virtual threads can run efficiently on a small number of underlying OS threads.

Key characteristics:

• Created and scheduled by the JVM, not the OS
• Low memory footprint – each virtual thread uses far less stack space
• No need to pool – unlike platform threads, you don’t need thread pools like ThreadPoolExecutor
• Drop-in replacement – they still implement java.lang.Thread, so most existing code works unchanged

Example:

Thread virtualThread = Thread.ofVirtual()
    .name("vt-")
    .unstarted(() -> {
        System.out.println("Running on virtual thread: "   Thread.currentThread());
    });

virtualThread.start();
virtualThread.join();

This looks like regular thread code—but it’s now lightweight and scalable.

Why Virtual Threads Improve Concurrency

Traditional server applications often use a thread-per-request model. Under high load, this leads to:

• Thread exhaustion
• High context-switching overhead
• Complex async code (e.g., CompletableFuture, reactive streams)

Virtual threads eliminate these issues by:

• Allowing massive concurrency – spawn one thread per request safely
• Simplifying code structure – keep using blocking I/O and straightforward logic
• Improving throughput – especially for I/O-bound tasks (e.g., HTTP calls, DB queries)

For example, with virtual threads, a web server can handle 10,000 concurrent requests with only a few dozen OS threads—each request runs on its own virtual thread.

How Project Loom Works Under the Hood

Project Loom introduces three key components:

1. Virtual Threads
   Lightweight threads that run on top of a carrier thread (an OS/platform thread).

2. Carrier Threads
   The actual OS threads that execute virtual threads. Managed by a ForkJoinPool by default.

3. Continuations (experimental)
   A lower-level construct that allows pausing and resuming code execution. Not yet public API, but powers future async patterns.

When a virtual thread blocks (e.g., on I/O), Loom suspends it instead of blocking the carrier thread. The carrier is then free to run another virtual thread. Once the I/O completes, the virtual thread is resumed on any available carrier.

This is transparent to developers—your Thread.sleep() or socket.read() just works, but without tying up OS threads.

Practical Example: High-Concurrency HTTP Server

Using virtual threads with Java’s built-in ExecutorService and HttpServer:

try (var server = HttpServer.create(new InetSocketAddress(8080), 0)) {
    server.createContext("/task", exchange -> {
        try {
            // Simulate blocking work (e.g., DB call)
            Thread.sleep(1000);
            String response = "Hello from "   Thread.currentThread();
            exchange.sendResponseHeaders(200, response.length());
            exchange.getResponseBody().write(response.getBytes());
        } finally {
            exchange.close();
        }
    });

    // Use virtual threads for handling requests
    var executor = Executors.newVirtualThreadPerTaskExecutor();
    server.setExecutor(executor);
    server.start();

    System.out.println("Server running on port 8080");
    Thread.sleep(60_000); // Run for 1 minute
}

Now, even with 10,000 concurrent clients making requests, the server stays responsive with minimal OS threads.

When to Use Virtual Threads

? Best for:

• I/O-bound tasks (web servers, microservices, DB access)
• Applications with high concurrency and low CPU usage
• Simplifying legacy blocking code

? Not ideal for:

• CPU-intensive work (they don’t improve raw compute performance)
• Replacing thread pools for parallel computation (stick with ForkJoinPool or parallelStream)

Also, avoid excessive synchronization (e.g., synchronized blocks), as they can block carrier threads and reduce scalability.

Migrating Existing Code

One of the biggest wins of Project Loom is backward compatibility. You don’t need to rewrite your code.

To adopt virtual threads:

• Replace Executors.newFixedThreadPool() with Executors.newVirtualThreadPerTaskExecutor()
• Avoid pooling virtual threads (they’re cheap to create)
• Use structured concurrency (new in Java 19 ) for better lifecycle management

Example migration:

// Old: limited pool of platform threads
// ExecutorService executor = Executors.newFixedThreadPool(10);

// New: unbounded virtual threads
ExecutorService executor = Executors.newVirtualThreadPerTaskExecutor();

Now every task runs on a virtual thread—simple and scalable.

Final Thoughts

Project Loom doesn’t replace reactive programming—but it offers a compelling alternative: write simple, readable, blocking-style code that scales like async.

With virtual threads, Java moves toward a future where high concurrency is no longer synonymous with complexity. Whether you're building microservices, batch processors, or APIs, Loom makes it easier to write efficient, maintainable code.

And the best part? You can start using it today—virtual threads are production-ready as of Java 21.

Basically: if you’re dealing with I/O and concurrency, give virtual threads a try. The performance and simplicity gains are real.

The above is the detailed content of Using Project Loom for Lightweight Concurrency in Java. For more information, please follow other related articles on the PHP Chinese website!