Concurrency in real systems question 129 of 180 senior
What is the servlet thread model, and what does async servlet processing change?
- One thread per application, dispatching all requests
- Correct: One container thread per in-flight request; async processing releases that thread while the work continues elsewhere and completes the response later
- A single event loop, like Node
- One thread per connection, kept for the connection's lifetime
Classic servlet processing binds a container thread to a request from the first byte to the last. A request that spends 500 ms waiting on a downstream service occupies a thread for 500 ms, so the thread pool size caps concurrency at pool size divided by latency.
AsyncContext.startAsync (and returning DeferredResult, Callable or a reactive type from a Spring
controller) releases the container thread and lets another thread complete the response later. The
thread is freed; the socket and the request state are not, so memory and connections still bound you.
The catch is the one from the rest of this repository: everything ThreadLocal is now on the wrong
thread, including the security context, the MDC and any open transaction. Virtual threads are the other
answer to the same problem, and the reason Spring Boot 3.2's
spring.threads.virtual.enabled=true exists: keep the simple blocking model and make the thread cheap
instead of removing it.
Quiz yourself on Concurrency in real systems Suggest a correction