Virtual Threads in Java

Virtual threads are lightweight Java threads introduced as a final feature in Java 21.

They let you write simple blocking-style code while supporting many more concurrent tasks than traditional platform threads.

Before virtual threads, Java threads were usually platform threads. A platform thread is backed by an operating system thread.

Platform threads are powerful, but they are relatively expensive. Because of that, backend applications usually use thread pools.

ExecutorService executor =
        Executors.newFixedThreadPool(100);

That creates a limit. If all 100 threads are blocked waiting for database calls, HTTP calls, or file I/O, new requests must wait even if the CPU is mostly idle.

Many virtual threads
        |
        v

+-------------------+
| Java runtime      |
+-------------------+
        |
        v

Smaller number of platform/carrier threads

When a virtual thread blocks on many common blocking operations, the JDK can unmount it from the carrier thread. The carrier thread can then run something else.

public class VirtualThreadExample {
    public static void main(String[] args) throws InterruptedException {
        Thread thread =
                Thread.startVirtualThread(() -> {
                    System.out.println(
                            "Running in " + Thread.currentThread()
                    );
                });

        thread.join();
    }
}

This creates and starts one virtual thread.

In server-style code, you will often see this pattern:

import java.util.concurrent.ExecutorService;
import java.util.concurrent.Executors;

public class VirtualThreadExecutorExample {
    public static void main(String[] args) {
        try (ExecutorService executor =
                     Executors.newVirtualThreadPerTaskExecutor()) {

            for (int i = 0; i < 10_000; i++) {
                int requestId = i;

                executor.submit(() -> {
                    handleRequest(requestId);
                });
            }
        }
    }

    static void handleRequest(int requestId) {
        // Blocking-looking code is okay here
        System.out.println("Handling request " + requestId);
    }
}

Instead of creating a small fixed pool and reusing threads, this style creates a new virtual thread for each task.

Many backend requests spend most of their time waiting:

Request starts
    ↓
Call database
    ↓
Wait
    ↓
Call payment service
    ↓
Wait
    ↓
Call inventory service
    ↓
Wait
    ↓
Return response

With platform threads, each waiting request ties up an expensive OS thread. With virtual threads, waiting is much cheaper.

This is one of the biggest practical mistakes.

Because virtual threads are cheap, it is tempting to start a huge number of tasks and assume everything will be fine.

for (String url : urls) {
    executor.submit(() -> callRemoteService(url));
}

But the remote service, database, connection pool, or API rate limit may not handle that much traffic.

Virtual threads are still Java Thread objects, so they can use ThreadLocal.

However, there is an important practical warning: if you create a huge number of virtual threads and each one stores large ThreadLocal values, memory usage can still become a problem.

Virtual threads and structured concurrency solve different but related problems.

Yes. In a typical Spring Boot REST API using Spring MVC, each incoming request is handled by a thread.

Traditionally, that request thread is a platform thread from the servlet container's thread pool. With virtual threads enabled, Spring Boot can handle request processing using virtual threads instead.

spring.threads.virtual.enabled=true

The benefit is that your controller and service code can often stay written in a normal blocking style.

@GetMapping("/orders/{id}")
public OrderDto getOrder(@PathVariable long id) {
    Order order = orderService.findOrder(id);
    Customer customer = customerClient.getCustomer(order.customerId());

    return OrderDto.from(order, customer);
}

This code may block while waiting for the database or another HTTP service. With platform threads, each blocked request holds onto an expensive operating system thread. With virtual threads, that waiting is much cheaper.

This does not mean every Spring Boot app automatically becomes faster. Virtual threads help most when the app is handling many concurrent requests that spend time waiting on blocking I/O, such as database calls, HTTP calls, or filesystem calls.

They help much less for CPU-heavy work, because virtual threads do not create more CPU cores.

A good interview answer is: