Современный подход к параллелизму в Java - Fork/Join Framework, CompletableFuture и виртуальные потоки (Project Loom)

Moving from Threads to Modern Tools

In the previous example, we created three threads manually. This helped speed up order processing, but as the load increases, this approach quickly becomes a problem. If a thousand orders come in, we can't launch a thousand threads: the system will simply hit its limit.

"A thread is like having a dedicated employee handle each order. But if there are too many clients, you'll have to hire an army of people. Instead, you need a smart manager who distributes tasks themselves."

In Java, this role is performed by higher-level tools: ExecutorService, ForkJoinPool, and CompletableFuture. They manage a thread pool—that is, they keep a limited number of workers and assign them tasks as they become available.

Example using CompletableFuture:

import java.util.concurrent.CompletableFuture;

public class OrderProcessingSmart {

    public static void main(String[] args) {

        CompletableFuture<Void> order1 = CompletableFuture.runAsync(() -> processOrder("Order No. 1"));
        CompletableFuture<Void> order2 = CompletableFuture.runAsync(() -> processOrder("Order No. 2"));
        CompletableFuture<Void> order3 = CompletableFuture.runAsync(() -> processOrder("Order No. 3"));

        CompletableFuture.allOf(order1, order2, order3).join();
        System.out.println("All orders processed!");
    }

    private static void processOrder(String name) {
        System.out.println(name + " started " + Thread.currentThread().getName());
        try {
            Thread.sleep(2000);
        } catch (InterruptedException e) {
            Thread.currentThread().interrupt();
        }
        System.out.println(name + " completed " + Thread.currentThread().getName());
    }
}

You don't need to manually create threads here—the system automatically decides how many workers to run, when they start, and how to wait for all results. The code is shorter, safer, and ready for real-world workloads.

How does CompletableFuture make decisions?

When you call CompletableFuture.runAsync() without specifying your own Executor, Java takes tasks and sends them to a common pool—ForkJoinPool.commonPool(). This is a special mechanism introduced in Java 7 that optimizes CPU usage.

Simply put, the JVM maintains multiple worker threads—usually the same number as the processor's cores. And as soon as one thread becomes free, it "steals" a task from another thread's queue (the Work-Stealing algorithm). This achieves almost full CPU utilization without idle time.

This is the fundamental difference from new Thread(). When you create threads manually, each thread lives on its own, takes up memory, and the JVM doesn't know how to balance them. A thread pool, however, is like a dispatcher: it monitors the state of the threads and decides which tasks to assign to which thread.

 CompletableFuture.runAsync(() -> processOrder("Order #1")); // executed inside ForkJoinPool.commonPool() 

But you can be even smarter: if you need to control the pool's behavior—for example, allocate more threads for I/O or limit CPU-bound tasks—you pass in your own ExecutorService:

 ExecutorService executor = Executors.newFixedThreadPool(4); CompletableFuture.runAsync(() -> processOrder("Order #1"), executor); CompletableFuture.runAsync(() -> processOrder("Order #2"), executor); 

Now allocation decisions are made not by the common JVM pool, but by your dedicated pool of four threads—this is a business setting, tailored to a specific workload or microservice.

That is, Java doesn't make decisions based on "guessing the best solution," but rather on "making the most efficient use of available cores and queued tasks."

When Project Loom arrives with virtual threads, the logic will remain the same, but the scheduler will be able to handle millions of tasks because virtual threads themselves don't consume system resources while waiting for I/O.

Loom's Virtual Threads as a Metaverse

Regular threads are like real buildings. Virtual threads are like apartments in the metaverse: millions of objects, almost no overhead, and real resources are needed only for actual work.

With Loom, thousands and millions of threads are like a skyscraper of virtual apartments: they weigh almost nothing and only work when needed.