Does Spring Boot create N threads to process N API requests?

Question

I am writing HTTP API server with Spring Boot 2.5. I am a little confused about how Spring Boot works with multiple HTTP requests?

Let's suppose Spring Boot application is processing N requests at a time. Does it create N threads for the Spring Boot application?

Answer 1

Does Spring Boot create N threads to process N requests?

Yes.

However, (1) this is not particularly a feature of the Spring Boot, and (2) you really should not worry about managing threads yourself, in the Web Container based applications (although, having an interest into internals, is good).

Spring Boot bases its HTTP communication on the Servlet API, i.e. Spring Boot uses Servlet Container (that is what's running as your Application Server, in the background) for handling HTTP communication and, generally, serve HTTP ^{Spring Boot uses Tomcat, as the default Servlet Container}.

Servlet API, on the other hand, defines HttpServletRequest and HttpServletResponse types, in order to facilitate working with HTTP Request and HTTP Response messages, respectively.

Now, the question becomes: How does Servlet Container handle HTTP requests?

Java™ Servlet Specification

• 2.1 Request Handling Methods
  • Generally the Web container handles concurrent requests to the same servlet by concurrent execution of the service method on different threads;
  • (Important, as well) The handling of concurrent requests to a Web application generally requires that the Web Developer design servlets that can deal with multiple threads executing within the service method at a particular time.

Also, note what does service() method documentation say:

Servlets typically run inside multithreaded servlet containers that can handle multiple requests concurrently. Developers must be aware to synchronize access to any shared resources such as files, network connections, and as well as the servlet's class and instance variables.

Story looks like this:

1. When the container sees, that incoming HTTP request message is mapped to Servlet instance, it instantiates two objects: HttpServletResponse and HttpServletRequest (and this happens per each request);

2. The container then creates (or allocates, from Thread Pool) a new thread for that request and invokes Servlet's service(..) method in that new thread, by passing those HttpServletRequest and HttpServletResponse objects into that method.

If this wouldn't have been designed so, server would have been blocking the execution per each HTTP message, until the latter completes.

Please, be aware, that:

There are two common scenarios in which a thread associated with a request can be sitting idle:

1. The thread needs to wait for a resource to become available or process data before building the response. For example, an application may need to query a database or access data from a remote web service before generating the response;
2. The thread needs to wait for an event before generating the response. For example, an application may have to wait for a JMS message, new information from another client, or new data available in a queue before generating the response.