Spring Boot 3 + Virtual Threads: Performance Testing and Pitfalls

Java 21's Virtual Threads are the culmination of Project Loom. Spring Boot 3.2 officially supports them. I recently ran tests in my project.

Configuration

# application.yml
spring:
  threads:
    virtual:
      enabled: true  # Spring Boot 3.2+

Or programmatically:

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

Test Environment

• CPU: Apple M2 Pro
• Memory: 16GB
• Spring Boot 3.2.1 + Java 21
• Benchmark tool: wrk, 1000 concurrent connections, 60s

Test Results

Scenario 1: Pure Blocking I/O (100ms sleep simulating DB)

10x QPS improvement. Virtual threads don't consume platform threads while blocked.

Scenario 2: CPU-Intensive (Fibonacci)

Nearly identical. Virtual threads don't speed up computation — they only solve blocking.

Pitfalls Encountered

1. Don't use synchronized inside virtual threads

// ❌ Wrong: synchronized pins the carrier thread
synchronized (this) {
    Thread.sleep(1000);
}

// ✅ Correct: use ReentrantLock
lock.lock();
try {
    Thread.sleep(1000);
} finally {
    lock.unlock();
}

2. Connection pools need to be larger

Originally, the Tomcat thread pool had 200 threads and the MySQL connection pool was also set to 200. After switching to virtual threads, you might have 10,000 concurrent requests, so the connection pool needs to scale accordingly. I recommend starting with HikariCP + maximumPoolSize=500.

3. ThreadLocal memory leaks

With massive numbers of virtual threads, every ThreadLocal consumes memory. Recommendation:

// Manually clean up after use
threadLocal.remove();

When Should You Use Virtual Threads?

In one sentence: Virtual threads make the "one request, one thread" model viable again. MVC no longer fears high concurrency.

References:

• OpenJDK — JEP 444: Virtual Threads
• Spring Boot 3.2 Documentation