Virtual threads shipped as a final feature in Java 21 and matured further in Java 25 (JEP 491 eliminates carrier-thread pinning inside synchronized blocks). The marketing says “millions of threads, almost free” — but what does that actually look like under a stopwatch? In this post we run reproducible benchmarks against platform threads, show where virtual threads win big (and where they don’t), and give you a clear decision table for your own code.

TL;DR

• Virtual threads are 28× faster for I/O-bound workloads (DB waits, HTTP calls) vs a 200-thread platform pool — one executor swap, no reactive libraries.
• For CPU-bound work (hashing, encoding, number crunching), virtual threads provide zero benefit — use ForkJoinPool instead.
• Each virtual thread costs ~few KB of heap vs ~1 MB native stack for a platform thread — enabling millions of concurrent tasks.
• The 28× gain shown here uses Thread.sleep(). Real I/O (DB/HTTP) yields similar but slightly lower gains depending on connection pool limits and network latency.
• Java 25 + JEP 491 eliminates the last major caveat (carrier pinning inside synchronized), making virtual threads safe for legacy synchronized code.

Thread Model: Platform vs Virtual

Platform threads map 1-to-1 with OS threads — each consumes ~1 MB of native stack. Virtual threads are JVM heap objects multiplexed onto a small pool of carrier threads (sized to CPU core count). When a virtual thread blocks on I/O, it unmounts from its carrier, freeing that carrier for another virtual thread immediately.

Memory Comparison

A 200-thread platform pool ≈ 200 MB of native stack. Running 10,000 virtual threads simultaneously costs a fraction of that in heap — and the JVM reclaims it as soon as each task completes.

Test Environment

All benchmarks below were run on the following hardware and software. Results will vary by machine, but the order-of-magnitude differences are consistent across environments:

Benchmark 1: I/O-Bound — 10,000 Concurrent Tasks

We simulate an I/O-bound workload by sleeping each task for 100 ms — this mimics a blocking database query or HTTP call. The same workload runs twice: once on a fixed platform-thread pool (200 threads, a realistic production cap), once on a virtual-thread-per-task executor.

import java.time.Duration;
import java.time.Instant;
import java.util.ArrayList;
import java.util.List;
import java.util.concurrent.*;
import java.util.stream.IntStream;

public class ThreadBenchmark {

    static final int      TASK_COUNT = 10_000;
    static final Duration IO_DELAY   = Duration.ofMillis(100);

    public static void main(String[] args) throws Exception {
        System.out.println("Platform threads (200 pool): " +
                run(Executors.newFixedThreadPool(200)));
        System.out.println("Virtual threads            : " +
                run(Executors.newVirtualThreadPerTaskExecutor()));
    }

    static Duration run(ExecutorService executor) throws Exception {
        Instant start = Instant.now();
        List<Future<Integer>> futures = new ArrayList<>(TASK_COUNT);

        try (executor) {                          // try-with-resources: calls close() / shutdown automatically
            IntStream.range(0, TASK_COUNT).forEach(taskIndex ->
                futures.add(executor.submit(() -> {
                    Thread.sleep(IO_DELAY);        // simulates a blocking DB query or HTTP call
                    return taskIndex;              // return value collected below to prevent silent failures
                }))
            );
        }                                         // blocks here until ALL tasks complete

        // Collect results — ensures no task failed silently
        int completedCount = 0;
        for (Future<Integer> future : futures) {
            future.get();                         // re-throws any exception from inside the task
            completedCount++;
        }
        System.out.println("  Tasks completed: " + completedCount);

        return Duration.between(start, Instant.now());
    }
}

How the Code Works

1. Task design — each of the 10,000 tasks calls Thread.sleep(IO_DELAY). Sleep is the canonical way to simulate a blocking call without needing real infrastructure in the benchmark.
2. Platform pool cap at 200 — each OS-managed thread consumes ~1 MB of native stack. 200 threads ≈ 200 MB stack space, a common production limit. Larger pools risk OOM on most JVMs.
3. Virtual-thread executor — Executors.newVirtualThreadPerTaskExecutor() creates one virtual thread per task. The JVM multiplexes all of them onto a small pool of carrier threads (sized to available CPU cores).
4. Collecting Future results — each submit() call returns a Future<Integer> that we collect into a list. After the executor shuts down, we call future.get() on each one. This ensures no task failed silently and re-throws any exception from inside the lambda.
5. Automatic shutdown — using the executor in try-with-resources calls close(), which initiates a graceful shutdown and blocks until every submitted task finishes — the Java 19+ preferred pattern over shutdown() + awaitTermination().
6. Wall-clock measurement — Instant.now() before and after captures end-to-end elapsed time including scheduling overhead, which is what a user of the API actually experiences.

Sample Output (I/O Benchmark)

Platform threads (200 pool):
  Tasks completed: 10000
  PT5.12S
Virtual threads:
  Tasks completed: 10000
  PT0.18S

Output Explanation

With a 200-thread pool, 10,000 tasks must queue. The pool processes them in 50 batches of 200; each batch takes ~100 ms (the sleep duration), giving roughly 5 seconds total. Virtual threads hold all 10,000 tasks in flight simultaneously at the JVM level. Wall-clock is dominated by a single 100 ms sleep plus ~80 ms of scheduling overhead — a 28× speedup from a single executor swap.

Run it yourself: java ThreadBenchmark.java on Java 21+ (no preview flag needed). Numbers vary by hardware, but the order-of-magnitude improvement is consistent.

⚠️ Benchmark Disclaimer: Real I/O vs Thread.sleep()

The 28× figure above uses Thread.sleep(), which is the ideal case for virtual threads — pure park/unpark with zero I/O overhead. In production scenarios the gains are real but more nuanced:

• HTTP calls: gains are substantial (10–20×) but capped by TCP connection setup, TLS handshake, and server-side throughput limits.
• Database queries: gains exist but JDBC connection pools (e.g. HikariCP capped at 20 connections) become the real bottleneck — virtual threads will wait at the pool, not the OS thread limit. Size your connection pool independently.
• Mixed workloads: if tasks combine I/O and CPU work, gains shrink proportionally to the CPU fraction.

Bottom line: Thread.sleep() benchmarks establish the theoretical ceiling. Real workloads will land below it — but still meaningfully above a constrained platform-thread pool for I/O-heavy code.

Benchmark 2: CPU-Bound — Virtual Threads Don’t Help

Virtual threads are not magic CPU cores. This benchmark runs 1,000 tasks that each do intensive computation (summing a large range of longs). Both executors should produce similar times — because the bottleneck is CPU cycles, not thread blocking.

import java.time.Duration;
import java.time.Instant;
import java.util.ArrayList;
import java.util.List;
import java.util.concurrent.*;
import java.util.stream.IntStream;

public class CpuBoundBenchmark {

    static final int TASK_COUNT      = 1_000;
    static final int ITERATIONS_PER_TASK = 10_000_000;   // CPU-intensive loop

    public static void main(String[] args) throws Exception {
        int coreCount = Runtime.getRuntime().availableProcessors();
        System.out.println("CPU cores available: " + coreCount);
        System.out.println("ForkJoinPool (" + coreCount + " threads): " +
                run(new ForkJoinPool(coreCount)));
        System.out.println("Virtual threads                      : " +
                run(Executors.newVirtualThreadPerTaskExecutor()));
    }

    static Duration run(ExecutorService executor) throws Exception {
        Instant start = Instant.now();
        List<Future<Long>> futures = new ArrayList<>(TASK_COUNT);

        try (executor) {
            IntStream.range(0, TASK_COUNT).forEach(taskIndex ->
                futures.add(executor.submit(() -> {
                    // Simulate CPU-intensive work: sum a large range
                    long total = 0;
                    for (int iteration = 0; iteration < ITERATIONS_PER_TASK; iteration++) {
                        total += iteration;        // pure computation, no I/O blocking
                    }
                    return total;
                }))
            );
        }

        // Collect all results to ensure no silent failures
        for (Future<Long> future : futures) {
            future.get();
        }

        return Duration.between(start, Instant.now());
    }
}

Sample Output (CPU Benchmark)

CPU cores available: 8
ForkJoinPool (8 threads): PT3.21S
Virtual threads          : PT3.19S

Times are essentially identical. Virtual threads sit on the same carrier pool as ForkJoinPool — they do not create extra parallelism. For CPU-bound work, use ForkJoinPool or newFixedThreadPool(coreCount) sized to your core count. See Java Concurrency Deep Dive for RecursiveTask examples.

Real-World Example: HTTP Calls with HttpClient

Here is how virtual threads integrate with java.net.http.HttpClient for parallel HTTP GET requests — a real-world scenario closer to production than a sleep loop:

import java.net.URI;
import java.net.http.*;
import java.time.Duration;
import java.time.Instant;
import java.util.ArrayList;
import java.util.List;
import java.util.concurrent.*;
import java.util.stream.IntStream;

public class HttpBenchmark {

    static final int  REQUEST_COUNT = 100;                        // keep low for public API courtesy
    static final String TARGET_URL  = "https://httpbin.org/delay/1"; // endpoint with 1-second delay

    public static void main(String[] args) throws Exception {
        HttpClient httpClient = HttpClient.newBuilder()
                .connectTimeout(Duration.ofSeconds(10))
                .executor(Executors.newVirtualThreadPerTaskExecutor()) // virtual-thread executor for async ops
                .build();

        Instant start = Instant.now();
        List<Future<Integer>> futures = new ArrayList<>(REQUEST_COUNT);

        try (ExecutorService taskExecutor = Executors.newVirtualThreadPerTaskExecutor()) {
            IntStream.range(0, REQUEST_COUNT).forEach(requestIndex ->
                futures.add(taskExecutor.submit(() -> {
                    HttpRequest httpRequest = HttpRequest.newBuilder()
                            .uri(URI.create(TARGET_URL))
                            .GET()
                            .build();
                    HttpResponse<Void> httpResponse = httpClient.send(
                            httpRequest, HttpResponse.BodyHandlers.discarding()
                    );                             // blocks the virtual thread; carrier is freed during wait
                    return httpResponse.statusCode();
                }))
            );
        }

        // Verify all requests completed successfully
        long successCount = futures.stream()
                .map(responseFuture -> {
                    try { return responseFuture.get(); }
                    catch (Exception ex) { return -1; }
                })
                .filter(statusCode -> statusCode == 200)
                .count();

        Duration elapsed = Duration.between(start, Instant.now());
        System.out.printf("Completed %d/%d requests in %s%n",
                successCount, REQUEST_COUNT, elapsed);
    }
}

With 100 requests each taking ~1 second, a platform pool of 10 threads would take ~10 seconds sequentially. Virtual threads send all 100 concurrently — total time ≈ ~1–2 seconds depending on network. The key: httpClient.send() is a blocking call that parks the virtual thread, freeing its carrier for other requests during the wait.

When NOT to Use Virtual Threads

When Platform Threads Still Win

• CPU-bound work. Hashing, encoding, image processing, number crunching — virtual threads do not give you more CPU cores. A ForkJoinPool sized to Runtime.getRuntime().availableProcessors() is still optimal. See Java Concurrency Deep Dive for a full RecursiveTask example.
• Long synchronized sections (Java 21–24). Virtual threads pin to their carrier when parked inside a synchronized block that contains a blocking call. On Java 25, JEP 491 eliminates this entirely. On Java 21–24, prefer ReentrantLock for sections that include blocking I/O.
• Native code / JNI. Native stack frames pin the carrier thread until the native call returns. If your code calls into native libraries that block (some older JDBC drivers, certain crypto libraries), that pinning risk persists until those libraries are updated.
• ThreadLocal-heavy code at scale. With millions of virtual threads, fat ThreadLocal values (e.g. large request-scoped objects) can consume significant heap. Migrate to ScopedValue (final in Java 25) for request-scoped data.

AI Prompts You Can Use

Use these in Claude, ChatGPT, or Cursor — attach the relevant file before running:

Prompt 1 — Audit Your Executors

What it does: Scans a codebase for every ExecutorService usage, classifies each as I/O-bound or CPU-bound, and recommends whether to switch to newVirtualThreadPerTaskExecutor(). Also flags synchronized blocks wrapping blocking calls — the carrier-pinning risk on Java 21–24.

When to use it: Start here. Get the full inventory before touching any code.

Scan this Java codebase for ExecutorService usages. For each one, classify the workload as I/O-bound or CPU-bound and recommend whether to switch to Executors.newVirtualThreadPerTaskExecutor(). Flag any synchronized blocks that contain blocking calls, as these cause carrier pinning on Java 21-24.

Prompt 2 — Find Pinning Risks

What it does: Locates every synchronized keyword in a file and evaluates whether the lock is held across a blocking call. Produces a list of risky sites and suggests ReentrantLock replacements with before/after code.

When to use it: After Prompt 1 flags pinning concerns, run this on each file with risky synchronized blocks before switching to virtual threads.

Find every 'synchronized' keyword in this file. For each one, assess whether the lock is held across a blocking I/O call (which causes virtual-thread carrier pinning on Java 21-24). Suggest ReentrantLock replacements with before/after code snippets.

Prompt 3 — Migrate a Thread Pool

What it does: Rewrites a class to use newVirtualThreadPerTaskExecutor() while preserving the existing task-submission API and shutdown semantics. Explains how try-with-resources replaces the old shutdown() + awaitTermination() two-liner.

When to use it: Once a workload is confirmed to be I/O-bound and safe to migrate.

Rewrite this class to use a virtual-thread-per-task executor. Preserve the task submission API and shutdown semantics. Explain how try-with-resources replaces the old shutdown() + awaitTermination() boilerplate.

Prompt 4 — Write a JMH Benchmark

What it does: Generates a proper JMH (Java Microbenchmark Harness) benchmark comparing a fixed platform-thread pool against a virtual-thread executor for 10,000 simulated HTTP tasks. Includes warmup iterations, measurement iterations, and microsecond output.

When to use it: When you need a publishable, reproducible benchmark to share with the team or include in performance documentation.

Generate a JMH benchmark that compares a FixedThreadPool(200) against a virtual-thread-per-task executor for 10,000 tasks, each performing an HTTP GET with java.net.http.HttpClient. Include warmup and measurement iterations, and output results in microseconds per operation.

See Also

• Java 21 to Java 25 LTS: Every Feature You Actually Need to Know
• Java Concurrency Deep Dive: CompletableFuture, ExecutorService, ForkJoinPool
• Java Streams API Deep Dive + Collectors Cookbook
• Modern Java Testing: JUnit 6 + AssertJ + Mockito 5 + Testcontainers
• Java 21 to Java 25 Upgrade Guide (with AI Prompts)
• AI Prompts Playbook: Upgrading Java 8 → 11 → 17 → 21 → 25
• Demystifying Thread Safety in Java: A Practical Guide
• From Raw Threads to Virtual Threads: A Developer’s Guide
• Solving the Producer-Consumer Problem with BlockingQueue
• ExecutorService.invokeAny(): Winning the Race for the First Result

FAQs

Do virtual threads need a special flag in Java 25?

No. Virtual threads are a final feature from Java 21 onward — no --enable-preview flag required. Java 25 adds JEP 491 which eliminates carrier-thread pinning inside synchronized blocks, making virtual threads safer to use with legacy synchronized code without any code changes.

How many virtual threads can I create?

Practically, millions. Each virtual thread is a JVM heap object costing a few hundred bytes, compared to the ~1 MB native stack that a platform thread requires. The JVM schedules them onto a small carrier pool (sized to available CPU cores) using cooperative unmounting on blocking calls.

Should I set a virtual-thread pool size?

No. Use Executors.newVirtualThreadPerTaskExecutor() and let the JVM manage the carrier pool. Placing a bound on virtual threads defeats the purpose — the carrier pool is already automatically sized to CPU count. Only apply back-pressure at the work queue level if you need to limit concurrency for a downstream resource (e.g., a DB with a 50-connection pool).

What happens to ThreadLocal with virtual threads?

ThreadLocal still works, but at the scale of millions of virtual threads, thread-local heap consumption can balloon. If you have large ThreadLocal values (request-scoped objects, connection handles), migrate to ScopedValue (final in Java 25), which has a structured lifetime tied to a call scope and is automatically cleaned up when the scope exits.

Do virtual threads work with Spring Boot?

Yes. Spring Boot 3.2+ includes first-class virtual thread support. Set spring.threads.virtual.enabled=true in your application.properties to switch Tomcat’s request-handling threads to virtual threads — no code changes needed. Spring MVC’s blocking handler model becomes highly concurrent without Reactive/WebFlux complexity.

Conclusion

For I/O-bound workloads — which is most of what microservices actually do — virtual threads are a straight win. A single executor swap gives you massive concurrency without reactive-stream ceremony. The 28× gain from the benchmark is real, though real DB/HTTP workloads will land slightly lower depending on connection pool limits and network latency. For CPU-bound work, a properly-sized ForkJoinPool still wins — virtual threads do not add cores. With Java 25 finalising JEP 491, the main remaining caveats (synchronized pinning, ThreadLocal bloat) are either eliminated or easy to address.

Further Reading

• JEP 444 — Virtual Threads (final in Java 21)
• JEP 491 — Synchronize Virtual Threads without Pinning (Java 25)
• JEP 506 — Scoped Values (final in Java 25)
• Project Loom — OpenJDK Wiki
• JEP 505 — Structured Concurrency (final in Java 25)