Setting `spring.threads.virtual.enabled=true` on a Spring Boot 3.2+ application running Java 21 changes how the embedded Tomcat handles requests. What changes, and which setting then bounds how many requests run at once?

## What the flag actually does `spring.threads.virtual.enabled=true` is a single property, available from Spring Boot 3.2 on Java 21 or later. For the web tier it makes Boot hand the embedded Tomcat's protocol handler an executor that creates a new virtual thread per task, replacing the fixed pool of platform threads. Boot applies the same treatment to other places it owns thread creation, such as scheduled tasks and asynchronous execution, but the request path is where the operational change is felt. Before: a request is handed to one of at most 200 platform threads; if it blocks on a database call, that OS thread is unusable for the duration. After: a request runs on a virtual thread; if it blocks, the virtual thread parks and its carrier is released to run something else. The programming model does not change — the code is still ordinary blocking, thread-per-request servlet code — but the cost of blocking collapses. ## The bound moves This is the interview answer. `server.tomcat.threads.max` bounded concurrency because the pool was finite. With virtual threads there is no pool to exhaust, so that property no longer caps how many requests execute at once. The remaining limits are connection-level: `server.tomcat.max-connections`, default 8192, and behind it `server.tomcat.accept-count`. The practical shift is from roughly 200 concurrent requests to potentially thousands. Whether that is good depends entirely on what the requests do. If they are mostly waiting on a fast downstream, throughput improves and latency under burst gets much better. If they contend for a scarce resource, nothing improved — the queue simply moved. A service with a 20-connection datasource that now admits 4,000 concurrent requests has 3,980 of them waiting for a connection, holding memory and half-built object graphs, and probably timing out at the caller after work was already spent on them. ## The bulkhead you did not know you had The old thread pool was doing two jobs: multiplexing work onto OS threads, and *limiting admission*. Only the first job is obsolete. Turning on virtual threads removes the second silently, so it has to be replaced deliberately: - Lower `server.tomcat.max-connections` to a number the service can genuinely serve, so overload is refused at the edge rather than queued inside. - Bound each scarce downstream explicitly — connection-pool size with a short acquisition timeout, a semaphore or concurrency limit around a fragile dependency. - Keep read timeouts on outbound calls. Cheap threads make it tempting to skip them; a slow dependency now accumulates thousands of parked requests instead of 200, which is a larger pile of pending work, not a smaller problem. ## What to re-check in the application - **ThreadLocal caching.** Anything that caches an expensive object per thread on the assumption that there are 200 long-lived threads now allocates one per request. Correctness usually holds — request-scoped context propagation still works because each request has its own thread — but memory and hit rates change. - **Pooled resources tied to threads.** Any code that assumed thread identity is stable across requests, or that a bounded pool was throttling it, deserves a look. - **Pinning.** On Java 21, blocking inside a `synchronized` block pinned the virtual thread to its carrier, which could starve the small carrier pool under load; JDK 24 removed that limitation. If you run on 21 with heavily synchronized blocking code, this is worth measuring rather than assuming. - **Monitoring.** The busy-request-threads metric that used to be the saturation signal goes flat and stops telling you anything. Replace it with in-flight request count, connection count, and downstream pool wait time before you switch, not after. ## Deciding whether to turn it on The honest test is what the service does with its time. A request-serving API dominated by waiting on I/O is the ideal case. A CPU-bound service gains nothing: the work still needs cores, and virtual threads do not create any. A service already running comfortably at 200 concurrency with headroom gains little beyond burst tolerance. Roll it out on one service, watch tail latency and downstream saturation, and confirm the new admission limits are the ones you chose rather than the 8192 default nobody looked at.