How does Spring Framework 7 take advantage of virtual threads compared to the traditional platform-thread model?

A traditional Spring MVC deployment runs each request on a thread drawn from a bounded platform-thread pool - Tomcat's default is around 200 threads. Every blocking call a request makes (a JDBC query, a downstream HTTP call) ties up one of those full OS threads for the entire wait, so total concurrent in-flight requests is hard-capped at the pool size regardless of how much of that time is spent simply waiting rather than computing.

spring.threads.virtual.enabled=true

Setting this property swaps the executor backing the embedded servlet container - and Spring's @Async/TaskExecutor infrastructure - to use JDK virtual threads instead. A virtual thread that blocks on I/O parks cheaply rather than occupying a scarce OS (platform) thread, so thousands of concurrent, mostly-waiting requests can be in flight using only a handful of actual OS threads underneath, all while the application code stays fully synchronous and imperative - no reactive rewrite required.

The gain is specific to I/O-bound waiting, though: virtual threads don't make CPU-bound work faster, since CPU-bound code still needs an actual core to run on. There's also a known pitfall - a virtual thread that blocks inside a synchronized block (or certain native/JNI calls) gets pinned to its underlying OS thread instead of being able to unmount while waiting, which can silently reintroduce the old scalability ceiling in code with heavy synchronized sections.