How Many Simultaneous Requests Can SpringBoot Handle?

Introduction

During a recent interview the author was asked whether each incoming IP maps to a dedicated thread in SpringBoot, prompting a deeper investigation into how many concurrent requests a SpringBoot application can actually handle.

Tomcat as the Limiting Factor

SpringBoot runs on an embedded Tomcat server, so the request‑handling capacity is determined by Tomcat’s configuration rather than SpringBoot itself.

Key Tomcat Parameters

server.tomcat.threads.min-spare : minimum number of worker threads (default 10).

server.tomcat.threads.max : maximum number of worker threads (default 200).

server.tomcat.max-connections : maximum number of simultaneous connections (default 8192).

server.tomcat.accept-count : length of the waiting queue (default 100).

These settings together define how many requests can be processed or queued.

Analogy

Imagine Tomcat as a restaurant: min‑spare are permanent chefs, max is the total chef count (permanent + temporary), max‑connections are the seats, and accept‑count are the stools at the door. Requests first occupy seats; if seats are full they wait on the stools; excess requests are rejected.

Consequently, the theoretical maximum number of requests SpringBoot can handle is max-connections + accept-count. Requests beyond this sum are dropped.

Practical Experiment

A small SpringBoot project was created with the following application.yml configuration to make the limits easy to observe:

server:
  tomcat:
    threads:
      # minimum threads
      min-spare: 10
      # maximum threads
      max: 15
    max-connections: 30
    accept-count: 10

A simple controller logs the client IP and thread name, then sleeps for 500 ms:

@GetMapping("/test")
public Response test1(HttpServletRequest request) throws Exception {
    log.info("ip:{},线程:{}", request.getRemoteAddr(), Thread.currentThread().getName());
    Thread.sleep(500);
    return Response.buildSuccess();
}

Using Apifox, 100 concurrent requests were sent to the endpoint. The test results (shown in the images) reveal that only 40 requests were processed—matching max-connections (30) + accept-count (10) —while the remaining 60 were discarded as expected. Because the maximum thread count is 15, the 40 accepted requests were handled in three batches: 15, then another 15, and finally 10.

The console log confirmed that the highest thread index reached 15, corroborating the configuration.

Summary of Findings

If the number of concurrent requests is lower than server.tomcat.threads.max , they are processed immediately. Requests exceeding this limit wait in the queue up to accept-count . When the total exceeds max-connections + accept-count , the surplus requests are dropped.

Extended Discussion: Concurrency Pitfalls

The article also explores why concurrent scenarios can produce unexpected values. Because Spring beans are singleton by default, shared mutable state (e.g., a global cookSum variable) can lead to race conditions where multiple threads read, modify, and write the same value, resulting in lost updates.

private int cookSum = 0;

@GetMapping("/test")
public Response test1(HttpServletRequest request) throws Exception {
    // simulate work
    cookSum += 1;
    log.info("做了{}道菜", cookSum);
    Thread.sleep(500);
    return Response.buildSuccess();
}

Resolving such issues requires proper synchronization, which is beyond the scope of this article.