Spring MVC (async) vs Spring WebFlux

Question

I'm trying to understand Spring WebFlux. The things I've found so far are reactive at the core, no Servlet API, no thread per request, HTTP 2, server pushes, application/stream+json.

But what is the difference between asynchronous calls in Spring MVC? I mean in Spring MVC when you return Future, DefferedResult and etc you get logic in the request handler (controller method) executed in a separate thread, so you can benefit from saving thread pool resources for dispatching requests as well.

So could you please highlight differences related to that? Why WebFlux is better here?

Thank you for your time very much!

Answer 1

Just an update on this topic in November 2024 to say Java JDK 21 now has released the concept of Virtual Thread.

Java threads are basically a wrapper for OS threads, and are known as platform threads. Therefore, threads are scarce resources, and therefore very valuable. If they are scarce, they are consequently expensive to have in abundance — approximately 2MB of memory is the cost to create a new thread.

Basically, we can say that threads are the “little place” where our code is executed.

Virtual thread

Forget all about threads being expensive and scarce resources. Virtual threads solve the problem of wasting time on threads, through a paradigm called coroutines. Virtual threads are still threads, and they act like threads, with the difference that they are no longer managed by the OS, like platform threads, but by the JVM. Now, for each platform thread, we will have an associated pool of virtual threads. How many virtual threads for each platform thread? As many as necessary. Each JVM can have millions of virtual threads.

With Java 21 and Spring Boot 3.2+, all you need is a parameter in application.properties

spring.threads.virtual.enabled=false

And your application will already be using virtual threads!

Before, there was a platform thread for each request. Now, for each task that needs to be executed, the platform thread will delegate this task to a virtual thread.

Instead of the platform thread itself executing the request, it delegates it to a Virtual Thread, and when this execution encounters blocking I/O, Java suspends this execution by placing the virtual thread context in the heap memory, and the platform thread is free to execute new tasks. As soon as the virtual thread is ready, it resumes execution.

Virtual threads are daemon threads, so they do not prevent the application from shutting down, unlike non-daemon threads in which the application ends when the thread ends.

Never use a pool

When we talk about thread pools or connection pools, we are implicitly saying: I have a resource that is limited, so I need to manage its use. But virtual threads are abundant, and a virtual thread pool should not be used.

The number of virtual threads we will have is equal to the number of simultaneous activities we execute. In short, for each simultaneous task you must instantiate a new virtual thread.

Answer 2

Servlet API is blocking I/O which requires 1 thread per HTTP request. Spring MVC async relies on Servlet APIs which only provides async behavior between container threads and request processing threads but not end to end.

Spring WebFlux on the other hand achieves concurrency by a fixed number of threads by using HTTP sockets and pushing chunks of data at a time through the sockets. This mechanism is called event loop, an idea made popular by Node.js. Such an approach is scalable and resilient. Spring 5's spring-webflux uses the event loop approach to provide async behavior.

More can be read from

• Servlet vs. Reactive
• Spring Boot performance battle
• Comparing WebFlux with Spring Web MVC

Answer 3

The Servlet async model introduces an async boundary between the container threads (1 Servlet request/thread model) and the processing of the request in your application. Processing can happen on a different thread or wait. In the end, you have to dispatch back to a container thread and read/write in a blocking way (InputStream and OutputStream are inherently blocking APIs).

With that model, you need many threads to achieve concurrency (because many of those can be blocked waiting for I/O). This costs resources and it can be a tradeoff, depending on your use case.

With non-blocking code, you only need a few threads to process a lot of requests concurrently. This is a different concurrency model; like any model, there are benefits and tradeoffs coming with it.

For more information about that comparison, this Servlet vs. Reactive stacks talk should be of interest.