Using Java Virtual Threads in SpringBoot: Configuration and Performance Comparison

Virtual threads, introduced in Java 19 and similar to Go goroutines, are lightweight thread abstractions managed by the JVM rather than the operating system, allowing a single OS thread to schedule thousands of virtual threads.

Unlike regular threads, virtual threads do not directly map to OS threads; they are scheduled by the JVM on top of ordinary threads, consuming far less memory and enabling the creation of millions of concurrent threads when sufficient heap is available.

To use virtual threads in a SpringBoot application (Java 20.0.2, SpringBoot 3.1.2), set the property spring.virtual-thread=true and add a configuration class that replaces the default task executor and Tomcat protocol handler with Executors.newVirtualThreadPerTaskExecutor():

@Configuration
@ConditionalOnProperty(prefix = "spring", name = "virtual-thread", havingValue = "true")
public class ThreadConfig {
    @Bean
    public AsyncTaskExecutor applicationTaskExecutor() {
        return new TaskExecutorAdapter(Executors.newVirtualThreadPerTaskExecutor());
    }

    @Bean
    public TomcatProtocolHandlerCustomizer<?> protocolHandlerCustomizer() {
        return protocolHandler -> protocolHandler.setExecutor(Executors.newVirtualThreadPerTaskExecutor());
    }
}

Performance testing compares an @Async service that sleeps for 50 ms. The test invokes the service 100 000 times and measures total execution time.

@Service
public class AsyncService {
    @Async
    public void doSomething(CountDownLatch latch) throws InterruptedException {
        Thread.sleep(50);
        latch.countDown();
    }
}

@Test
public void testAsync() throws InterruptedException {
    long start = System.currentTimeMillis();
    int n = 100000;
    CountDownLatch latch = new CountDownLatch(n);
    for (int i = 0; i < n; i++) {
        asyncService.doSomething(latch);
    }
    latch.await();
    long end = System.currentTimeMillis();
    System.out.println("耗时：" + (end - start) + "ms");
}

Results show ordinary threads taking about 678 seconds (over 10 minutes), while virtual threads finish in roughly 3.9 seconds—an improvement of nearly 200×.

A similar HTTP benchmark defines a simple GET endpoint that also sleeps 50 ms. Using JMeter with 500 concurrent threads for 10 000 requests, regular threads exhibit median latencies above 150 ms, whereas virtual threads keep the maximum latency under 100 ms, demonstrating far better resource utilization.

@RequestMapping("/get")
public Object get() throws Exception {
    Thread.sleep(50);
    return "ok";
}

In summary, virtual threads provide substantial performance gains for IO‑bound workloads such as web services, database or cache calls, but the benefit diminishes for CPU‑bound tasks. Upgrading legacy Java 8 applications to a recent JDK and enabling virtual threads can dramatically improve scalability.