As I refactored our e-commerce platform to handle Black Friday traffic, I faced constant thread exhaustion errors under load. That’s when I discovered Java 21’s Virtual Threads integrated with Spring Boot 3.2. Let me show you how this solution transformed our performance while keeping code simple. Stick around - the results might surprise you.

Virtual Threads work differently than traditional threads. Instead of each thread tying up an OS resource, the JVM manages lightweight threads efficiently. Imagine handling 10,000 concurrent requests with just a few OS threads. How is that possible? The magic happens when threads block - Virtual Threads park themselves, freeing the carrier thread for other work. This means we can create millions of threads without crashing the system.

To get started, ensure you’re using Java 21+ and Spring Boot 3.2+. Here’s the essential Maven setup:

<properties>
    <java.version>21</java.version>
</properties>

<dependencies>
    <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-web</artifactId>
    </dependency>
</dependencies>

Configuration is straightforward. We’ll modify Tomcat’s thread executor and Spring’s async task executor:

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

@Bean(TaskExecutionAutoConfiguration.APPLICATION_TASK_EXECUTOR_BEAN_NAME)
public AsyncTaskExecutor asyncTaskExecutor() {
    return new TaskExecutorAdapter(Executors.newVirtualThreadPerTaskExecutor());
}

Notice we’re not configuring thread pools. Virtual Threads eliminate that complexity - the JVM handles scaling automatically. For database operations, standard Spring Data JPA works seamlessly:

@Service
public class UserService {
    
    private final UserRepository userRepository;
    
    public UserService(UserRepository userRepository) {
        this.userRepository = userRepository;
    }
    
    public User getUserWithOrders(Long userId) {
        return userRepository.findByIdWithOrders(userId)
            .orElseThrow(() -> new ResponseStatusException(HttpStatus.NOT_FOUND));
    }
}

What happens when this method blocks on database I/O? The Virtual Thread unmounts from the carrier thread, allowing it to execute other tasks. No thread pool tuning needed!

For REST controllers, we get massive concurrency with standard code:

@RestController
public class OrderController {
    
    private final OrderService orderService;
    
    public OrderController(OrderService orderService) {
        this.orderService = orderService;
    }
    
    @GetMapping("/users/{userId}/orders")
    public List<Order> getUserOrders(@PathVariable Long userId) {
        return orderService.getOrdersByUser(userId);
    }
}

External API calls benefit equally. This WebClient integration maintains responsiveness during network delays:

@Service
public class PaymentService {
    
    private final WebClient webClient;
    
    public PaymentService(WebClient.Builder webClientBuilder) {
        this.webClient = webClientBuilder.baseUrl("https://payment-gateway.com").build();
    }
    
    public Mono<PaymentStatus> processPayment(Order order) {
        return webClient.post()
            .uri("/payments")
            .bodyValue(order)
            .retrieve()
            .bodyToMono(PaymentStatus.class);
    }
}

Monitoring is critical. Actuator’s thread dump endpoint reveals Virtual Thread behavior:

management:
  endpoints:
    web:
      exposure:
        include: threaddump

Check thread dumps after deployment. You’ll see hundreds of Virtual Threads with names like “VirtualThread[#1001]/runnable” - proof they’re working!

But does it actually improve performance? Our tests showed 5x more requests per second compared to 200-platform-thread pools. Latency remained stable under load where traditional setups collapsed. Why? Because blocking operations no longer monopolize scarce OS resources.

For database tuning, remember: Connection pools still matter. Set your HikariCP maximum pool size based on database capabilities, not thread counts. Virtual Threads wait efficiently for connections without consuming OS resources.

Encountering issues? Check these common pitfalls:

1. Native image compilation not yet supporting Virtual Threads
2. Synchronized blocks pinning threads (replace with ReentrantLock)
3. Thread-local variables requiring careful migration

What surprised me most? How little code changed. We kept our imperative programming style while gaining reactive-like scalability. The shift felt natural - no complex callback chains or operators to learn.

The results speak for themselves. After deployment, our 95th percentile response times dropped from 2.3 seconds to 190 milliseconds during peak traffic. Server costs decreased by 40% thanks to better resource utilization. Not bad for a configuration change!

Ready to try it yourself? Create a simple controller, load test it with JMeter, and watch Virtual Threads handle concurrency gracefully. Your turn - what performance challenges could this solve in your projects?

Found this useful? Share it with your team and leave a comment about your experience. Let’s build faster web applications together!