Reactive Programming vs Virtual Threads: Choosing the Right Concurrency Model in Java
For years, reactive programming with Project Reactor and RxJava was the answer to Java’s thread-per-request scaling problem. Now Java virtual threads offer a simpler alternative that achieves similar throughput without reactive complexity. Therefore, this guide compares both approaches head-to-head, shows when each makes sense, and provides a practical migration path from reactive to virtual threads.
The Problem Both Solve: Thread-Per-Request Doesn’t Scale
Traditional Java web servers allocate one platform thread per request. With 2,000 concurrent requests, you need 2,000 threads — each consuming ~1MB of stack memory. That’s 2GB just for thread stacks, plus context switching overhead. At 10,000 concurrent connections, the JVM spends more time switching threads than doing useful work.
Reactive programming solved this with non-blocking I/O on a small thread pool (typically CPU core count). A single thread handles hundreds of connections by never blocking — it processes events, starts I/O, and moves to the next event while I/O completes asynchronously. Virtual threads solve the same problem differently: they’re lightweight threads (~1KB vs ~1MB) that can block freely because the JVM parks them efficiently during I/O. Moreover, virtual threads look like regular blocking code — no Mono/Flux, no callback chains, no reactive operators.
// Traditional blocking — doesn't scale past ~2K concurrent requests
@GetMapping("/orders/{id}")
public OrderDTO getOrder(@PathVariable Long id) {
Order order = orderRepo.findById(id); // Blocks platform thread
Customer customer = customerClient.get(order.getCustomerId()); // Blocks again
return new OrderDTO(order, customer);
}
// Reactive — scales to 100K+ connections but complex code
@GetMapping("/orders/{id}")
public Mono<OrderDTO> getOrder(@PathVariable Long id) {
return orderRepo.findById(id) // Returns Mono, non-blocking
.flatMap(order ->
customerClient.get(order.getCustomerId()) // Chain operations
.map(customer -> new OrderDTO(order, customer))
)
.onErrorResume(e -> Mono.error(new OrderNotFoundException(id)));
}
// Virtual threads — scales like reactive, reads like blocking
@GetMapping("/orders/{id}")
public OrderDTO getOrder(@PathVariable Long id) {
Order order = orderRepo.findById(id); // Blocks virtual thread (cheap)
Customer customer = customerClient.get(order.getCustomerId()); // Blocks again (still cheap)
return new OrderDTO(order, customer);
// Runs on a virtual thread — JVM handles the non-blocking I/O underneath
}When to Use Virtual Threads
Virtual threads are the right choice for most new I/O-bound applications. If your service primarily calls databases, HTTP APIs, and message brokers — and you spend most time waiting for I/O responses — virtual threads give you reactive-level throughput with blocking-style code. Furthermore, your existing libraries, debugging tools, and stack traces work unchanged.
// Spring Boot with virtual threads — just one property
// application.yml
// spring:
// threads:
// virtual:
// enabled: true
// Parallel I/O with virtual threads — structured concurrency
import java.util.concurrent.StructuredTaskScope;
public OrderDetails getOrderDetails(Long orderId) {
try (var scope = new StructuredTaskScope.ShutdownOnFailure()) {
// All three calls execute in parallel on virtual threads
var orderFuture = scope.fork(() -> orderRepo.findById(orderId));
var paymentFuture = scope.fork(() -> paymentClient.getPayment(orderId));
var shippingFuture = scope.fork(() -> shippingClient.getTracking(orderId));
scope.join(); // Wait for all to complete
scope.throwIfFailed(); // Propagate any exception
return new OrderDetails(
orderFuture.get(),
paymentFuture.get(),
shippingFuture.get()
);
}
// Total time: max(order, payment, shipping) instead of sum
}Key advantages of virtual threads: standard blocking code that developers already know, full stack traces for debugging (no reactive stack traces), compatible with existing JDBC drivers, HTTP clients, and frameworks, and structured concurrency for parallel I/O with proper error handling.
When to Keep Reactive
Reactive programming still has advantages for specific scenarios. If you need backpressure (controlling data flow when a consumer can’t keep up), reactive is superior. Streaming data processing — reading a 10GB file and transforming it record by record without loading it all into memory — is naturally reactive. Additionally, if you’re building event-driven architectures with complex operator chains (combine, merge, retry with backoff, circuit breaker), reactive operators express these patterns more elegantly than imperative code.
// Reactive excels at streaming with backpressure
// Processing a large dataset record-by-record without OOM
Flux.from(databaseCursorPublisher)
.bufferTimeout(100, Duration.ofMillis(500)) // Batch for efficiency
.flatMap(batch -> processAndEnrich(batch), 4) // 4 concurrent batches
.onBackpressureBuffer(1000) // Buffer if downstream is slow
.doOnNext(result -> metrics.incrementProcessed())
.subscribe(result -> outputSink.write(result));
// Complex retry logic expressed declaratively
webClient.get()
.uri("/api/data")
.retrieve()
.bodyToMono(Data.class)
.retryWhen(Retry.backoff(3, Duration.ofSeconds(1))
.filter(ex -> ex instanceof WebClientResponseException.ServiceUnavailable)
.onRetryExhaustedThrow((spec, signal) -> signal.failure())
)
.timeout(Duration.ofSeconds(10))
.onErrorResume(TimeoutException.class, e -> Mono.just(Data.fallback()));Migration from Reactive to Virtual Threads
If you have an existing reactive codebase and want to migrate, do it incrementally. You don’t need to rewrite everything at once. Start with new endpoints using virtual threads while keeping existing reactive code running. Gradually migrate simple reactive endpoints (those without backpressure or complex operators) to blocking code on virtual threads.
// Step 1: Keep reactive endpoints that benefit from it
// Step 2: New endpoints use virtual threads
// Step 3: Migrate simple endpoints
// Before: Simple reactive that doesn't need to be reactive
public Mono<UserDTO> getUser(Long id) {
return userRepo.findById(id)
.map(UserMapper::toDTO)
.switchIfEmpty(Mono.error(new UserNotFoundException(id)));
}
// After: Simpler blocking code on virtual threads
public UserDTO getUser(Long id) {
User user = userRepo.findById(id);
if (user == null) throw new UserNotFoundException(id);
return UserMapper.toDTO(user);
}
// Keep reactive: This genuinely benefits from reactive operators
public Flux<PriceUpdate> streamPrices(String symbol) {
return priceService.subscribe(symbol)
.filter(update -> update.getChange() > 0.01)
.sample(Duration.ofMillis(100))
.onBackpressureDrop();
}
Performance Comparison
In benchmarks with I/O-bound workloads (database queries, HTTP calls), virtual threads and reactive achieve comparable throughput — both handle 50,000+ concurrent connections on a single server. The difference is in CPU-bound scenarios: reactive has slightly better CPU efficiency due to fewer context switches, while virtual threads use slightly more memory per task. Consequently, for the vast majority of web services, the performance difference is negligible.
Related Reading:
- Spring Boot with Virtual Threads in Production
- Java Pattern Matching Guide
- GraalVM Native Images with Spring Boot
Resources:
In conclusion, virtual threads are the right default for new Java applications — they provide reactive-level scalability with imperative simplicity. Keep reactive programming for streaming data, backpressure scenarios, and complex event-driven flows. For existing reactive codebases, migrate incrementally starting with the simplest endpoints.