In this tutorial, we’ll explore concurrency in reactive programs written with Spring WebFlux<\/a>.<\/p>\n We’ll begin by discussing concurrency in relation to reactive programming. After that, we’ll explore how Spring WebFlux offers concurrency abstractions over different reactive server libraries.<\/p>\n A typical web application comprises of several complex, interacting parts<\/strong>. Many of these interactions are blocking in nature<\/strong> like, for example, those involving a database call to fetch or update data.\u00a0 Several others, however, are independent and can be performed concurrently,<\/strong> possibly in parallel.<\/p>\n For instance, two user requests to a web server can be handled by different threads.<\/strong> On a multi-core <\/em>platform, this has an obvious benefit in terms of the overall response time. Hence, this model of concurrency is known as the thread-per-request model<\/em><\/strong>:<\/p>\n In the diagram above, each thread handles a single request at a time.<\/p>\n While thread-based concurrency solves a part of the problem for us, it does nothing to address the fact that most of our interactions within a single thread are still blocking<\/strong>. Moreover, the native threads we use to achieve concurrency in Java come at a significant cost in terms of context switches.<\/p>\n Meanwhile, as web applications face more and more requests, the thread-per-request model<\/em> starts to fall short of expectations<\/strong>.<\/p>\n Consequently, what we need is a concurrency model which can help us handle increasingly more requests with relatively less number of threads<\/strong>. This is one of the primary motivations for adopting reactive programing<\/a>.<\/strong><\/p>\n Reactive programming helps us structure the program in terms of data flows and the propagation of change through them<\/strong>. Hence, in a completely non-blocking environment, this can enable us to achieve higher concurrency with better resource utilization.<\/p>\n However, is reactive programming a complete departure from thread-based concurrency? While this is a strong statement to make, reactive programming certainly has a very different approach to the usage of threads to achieve concurrency<\/strong>. So, the fundamental difference that reactive programming brings on is asynchronicity.<\/strong><\/p>\n In other words, the program flow transforms from a sequence of synchronous operations, into an asynchronous stream of events.<\/p>\n For instance, under the reactive model, a read call to the database does not block the calling thread while data is fetched. The call immediately returns a publisher that others can subscribe to<\/strong>. The subscriber can process the event after it occurs and may even further generate events itself:<\/p>\n Above all, reactive programming does not emphasize on which thread events should be generated and consumed. Emphasis is, rather, on structuring the program as an asynchronous event stream<\/strong>.<\/p>\n The publisher and subscriber here do not need to be part of the same thread. This helps us in getting better utilization of available threads and hence higher overall concurrency.<\/strong><\/p>\n There are several programming models that describe a reactive approach to concurrency<\/strong>.<\/p>\n In this section, we’ll examine a few of them to understand how reactive programming achieves higher concurrency with fewer threads.<\/p>\n One of such reactive asynchronous programming model for servers is the event loop<\/em> model<\/em><\/strong>:<\/p>\n Above, is an abstract design of an event loop <\/em>that presents the ideas of reactive asynchronous programming:<\/p>\n The event loop<\/em> model<\/em> is implemented in a number of platforms including Node.js<\/a><\/em>, Netty<\/a><\/em>, and Ngnix<\/a><\/em>. They offer much better scalability than traditional platforms like Apache HTTP Server<\/a><\/em>, Tomcat<\/a><\/em>, or JBoss<\/a><\/em>.<\/p>\n Now, we have enough insights into reactive programming and its concurrency model, to explore the subject in Spring WebFlux.<\/p>\n WebFlux is<\/strong> the <\/b>Spring<\/strong>‘s<\/strong> reactive-stack web framework<\/strong>, which was added in version 5.0.<\/p>\n Let’s explore the server-side stack of Spring WebFlux to understand how it complements the traditional web stack in Spring:<\/p>\n As we can see, Spring WebFlux sits parallel to the traditional web framework in Spring and does not necessarily replace it<\/strong>.<\/p>\n There are a few important points to note here:<\/p>\n As we have discussed earlier, reactive programs tend to work with just a few threads<\/strong> and make the most of them. However, the number and nature of threads depend upon the actual Reactive Stream API runtime that we choose.<\/p>\n To clarify, Spring WebFlux can adapt to different runtimes through a common API provided by HttpHandler<\/em><\/strong>. This API is a simple contract with just one method that provides an abstraction over different server APIs like Reactor Netty, Servlet 3.1 API, or Undertow APIs.<\/p>\n Let’s now understand the threading model implemented in a few of them.<\/p>\n While Netty is the default server in a WebFlux application, it’s just a matter of declaring the right dependency to switch to any other supported server<\/strong>:<\/p>\n While it’s possible to observe the threads created in a Java Virtual Machine in a number of ways, it’s quite easy just to pull them from the Thread<\/em> class itself:<\/p>\n As we said, Reactor Netty<\/a> is the default embedded server in the Spring Boot WebFlux starter. Let’s try to see the threads that Netty creates by default. Hence, in the beginning, we’ll not add any other dependencies or use WebClient. So, if we start a Spring WebFlux application created using its SpringBoot starter, we can expect to see some default threads it creates:<\/p>\n Note that, apart from a normal thread for the server, Netty spawns a bunch of worker threads for request processing<\/strong>. These typically are not more than available CPU cores.<\/strong> This is the output on a quad-core machine. We’d also see a bunch of housekeeping threads typical to a JVM environment, but they are not important here.<\/p>\n Netty uses the event loop model to provide highly scalable concurrency in a reactive asynchronous manner.<\/strong> Let’s see how Netty implements event loop levering Java NIO to provide this scalability<\/strong>:<\/p>\n Here, EventLoopGroup <\/em>manages one or more EventLoop<\/em> which must be continuously running<\/strong>. Hence, it’s not recommended to create more EventLoops<\/em>\u00a0than the number of available cores.<\/strong><\/p>\n The EventLoopGroup <\/em>further assigns an EventLoop <\/em>to each newly created Channel<\/em>. Thus, for the lifetime of a Channel<\/em>, all operations are executed by the same thread.<\/p>\n Spring WebFlux is also supported on a traditional Servlet Container like Apache Tomcat<\/a>.<\/strong><\/p>\n WebFlux relies on the Servlet 3.1 API with non-blocking I\/O<\/strong>. While it uses Servlet API behind a low-level adapter, Servlet API is not available for direct usage.<\/p>\n Let’s see what kind of threads we expect in a WebFlux application running on Tomcat:<\/p>\n The number and type of threads which we can see here are quite different from what we observed earlier.<\/p>\n To begin with, Tomcat starts with more worker threads, which defaults to ten<\/strong>. Of course, we’ll also see some housekeeping threads typical to the JVM, and the Catalina container, which we can ignore for this discussion.<\/p>\n Let’s understand the architecture of Tomcat with Java NIO to correlate it with the threads we see above.<\/p>\n Tomcat 5 onward supports NIO in its Connector component, which is primarily responsible for receiving the requests<\/strong>.<\/p>\n The other Tomcat component is the Container component, which is responsible for the container management functions.<\/p>\n The point of interest for us here is the threading model that the Connector component implements to support NIO. It is comprised of Acceptor<\/em>, Poller, <\/em>and Worker <\/em>as part of the NioEndpoint<\/em> module:<\/p>\n Tomcat spawns one or more threads for Acceptor<\/em>, Poller<\/em>, and Worker<\/em> with typically a thread pool dedicated to Worker<\/em><\/strong>.<\/p>\n While a detailed discussion on Tomcat architecture is beyond the scope of this tutorial, we should now have enough insights to understand the threads we saw earlier.<\/p>\n WebClient<\/em><\/a> <\/strong>is the reactive HTTP client that is part of Spring WebFlux<\/strong>. We can use it anytime we require REST-based communication and enables us to create applications that are end-to-end<\/em> reactive<\/em>.<\/p>\n As we have seen before, reactive applications work with just a few threads, and so, there is no margin for any part of the application to block a thread. Hence, WebClient<\/em> plays a vital role in helping us realize the potential of WebFlux.<\/p>\n Using WebClient<\/em> is quite simple as well. We do not need to include any specific dependencies as it’s part of Spring WebFlux<\/strong>.<\/p>\n Let’s create a simple REST endpoint which returns a Mono<\/em><\/a>:<\/p>\n Then, we’ll use WebClient<\/em> to call this REST endpoint and consume the data reactively:<\/p>\n Here, we’re also printing the threads that are created using the method we discussed earlier.<\/p>\n So, how does the threading model work in the case of WebClient<\/em>?<\/p>\n Well, not surprisingly, WebClient<\/em> also implements concurrency using the event loop model<\/em><\/strong>. Of course, it relies on the underlying runtime to provide the necessary infrastructure.<\/p>\n If we’re running WebClient<\/em> on the Reactor Netty, it shares the event loop that Netty uses for the server<\/strong>. Hence, in this case, we may not notice much difference in the threads that are created.<\/p>\n However, WebClient<\/em> is also supported on a Servlet 3.1+ container like Jetty, but the way it works there is different<\/strong>.<\/p>\n If we compare the threads that are created on a WebFlux application running Jetty<\/a> with and without WebClient<\/em>, we’ll notice a few additional threads.<\/p>\n Here, WebClient<\/em> has to create its event loop<\/em>. So, we can see a fixed number of processing threads that this event loop creates:<\/p>\n In some cases,<\/strong> having a separate thread pool for client and server can provide better performance<\/strong>. While it’s not the default behavior with Netty, it’s always possible to declare a dedicated thread pool for WebClient<\/em> if needed.<\/p>\n We’ll see how this is possible in a later section.<\/p>\n As we have seen earlier, even a simple application usually consists of several parts that need to be connected.<\/strong><\/p>\n Typical examples of these parts include databases and message brokers. The existing libraries to connect with many of them are still blocking, but that is changing fast.<\/strong><\/p>\n There are several databases now that offer reactive libraries for connectivity<\/strong>. Many of these libraries are available within Spring Data<\/a><\/strong>, while we can use others directly as well.<\/p>\n The threading model these libraries use is of particular interest to us.<\/p>\n Spring Data MongoDB<\/a> provides reactive repository support for MongoDB built on top of the MongoDB Reactive Streams driver<\/a>. Most notably, this driver fully implements the Reactive Streams API to provide asynchronous stream processing<\/strong> with non-blocking back-pressure<\/em>.<\/p>\n Setting up support for the reactive repository for MongoDB in a Spring Boot application is as simple as adding a dependency:<\/p>\n This will allow us to create a repository, and use it to perform some basic operations on MongoDB in a non-blocking manner:<\/p>\n So, what kind of threads can we expect to see when we run this application on the Netty server?<\/p>\n Well, not surprisingly, we’ll not see much difference as a<\/strong> Spring Data reactive repository makes use of the same event loop that is available for the server.<\/strong><\/p>\n2. The Motivation for Reactive Programming<\/h2>\n
![\"\"](\"https:\/\/www.baeldung.com\/wp-content\/uploads\/2020\/08\/Thread-per-Request-Model.jpg\")
<\/a><\/p>\n3. Concurrency in Reactive Programming<\/h2>\n
![\"\"](\"https:\/\/www.baeldung.com\/wp-content\/uploads\/2020\/08\/Reactive-Model.jpg\")
<\/a><\/p>\n4. Event Loop<\/h2>\n
![\"\"](\"https:\/\/www.baeldung.com\/wp-content\/uploads\/2020\/08\/Event-Loop.jpg\")
<\/a><\/p>\n\n
5. Reactive Programming with Spring WebFlux<\/h2>\n
![\"\"](\"https:\/\/www.baeldung.com\/wp-content\/uploads\/2020\/08\/Spring-Web-Stack.jpg\")
<\/a><\/p>\n\n
6. Threading Model in Supported Runtimes<\/h2>\n
<dependency>\r\n <groupId>org.springframework.boot<\/groupId>\r\n <artifactId>spring-boot-starter-webflux<\/artifactId>\r\n <exclusions>\r\n <exclusion>\r\n <groupId>org.springframework.boot<\/groupId>\r\n <artifactId>spring-boot-starter-reactor-netty<\/artifactId>\r\n <\/exclusion>\r\n <\/exclusions>\r\n<\/dependency>\r\n<dependency>\r\n <groupId>org.springframework.boot<\/groupId>\r\n <artifactId>spring-boot-starter-tomcat<\/artifactId>\r\n<\/dependency><\/code><\/pre>\nThread.getAllStackTraces()\r\n .keySet()\r\n .stream()\r\n .collect(Collectors.toList());<\/code><\/pre>\n6.1. Reactor Netty<\/h3>\n
![\"\"](\"https:\/\/www.baeldung.com\/wp-content\/uploads\/2020\/08\/1.jpg\")
<\/a><\/p>\n![\"\"](\"https:\/\/www.baeldung.com\/wp-content\/uploads\/2020\/08\/Netty-Threading-Model.jpg\")
<\/a><\/p>\n6.2. Apache Tomcat<\/h3>\n
![\"\"](\"https:\/\/www.baeldung.com\/wp-content\/uploads\/2020\/08\/2-841x1024-1.jpg\"){kind=spacer}
<\/a><\/p>\n![\"\"](\"https:\/\/www.baeldung.com\/wp-content\/uploads\/2020\/08\/Tomcat-NIO-Connector.jpg\")
<\/a><\/p>\n7. Threading Model in WebClient<\/em><\/h2>\n
7.1. Using WebClient<\/em><\/h3>\n
@GetMapping(\"\/index\")\r\npublic Mono<String> getIndex() {\r\n return Mono.just(\"Hello World!\");\r\n}<\/code><\/pre>\nWebClient.create(\"http:\/\/localhost:8080\/index\").get()\r\n .retrieve()\r\n .bodyToMono(String.class)\r\n .doOnNext(s -> printThreads());<\/code><\/pre>\n7.2. Understanding the Threading Model<\/h3>\n
![\"\"](\"https:\/\/www.baeldung.com\/wp-content\/uploads\/2020\/08\/3.jpg\")
<\/a><\/p>\n8. Threading Model in Data Access Libraries<\/h2>\n
8.1. Spring Data MongoDB<\/h3>\n
<dependency>\r\n <groupId>org.springframework.boot<\/groupId>\r\n <artifactId>spring-boot-starter-data-mongodb-reactive<\/artifactId>\r\n<\/dependency><\/code><\/pre>\npublic interface PersonRepository extends ReactiveMongoRepository<Person, ObjectId> {\r\n}\r\n.....\r\npersonRepository.findAll().doOnComplete(this::printThreads);<\/code><\/pre>\n