· Aseem Savio · —
Is The Thread-per-Request Model a Good Thing After Project Loom?
Project Loom's virtual threads make Java's thread-per-request model efficient again, and show why virtual threads should not be pooled.
Java server applications typically tend to be multi-threaded to serve multiple users simultaneously.
Thread-per-Request Model
Spinning up new threads for new requests is limited by hardware and can lead to an OutOfMemoryError. Threads are also expensive to create in memory and time.
Thread Pooling
Pooling threads using ExecutorService helps manage expensive resources, though thread counts remain constrained. Brian Goetz provides a formula in “Java Concurrency in Practice” for ideal pool size based on wait and service times. Asynchronous libraries offer alternatives but can conflict with the platform’s unit of concurrency.
Project Loom & Virtual Threads
Project Loom introduces lightweight Virtual Threads managed by the JDK scheduler rather than directly by the operating system.
How Virtual Threads Work
Blocking a virtual thread on I/O unmounts it from the platform thread, allowing the scheduler to run other virtual threads. Once unblocked, it resumes execution, enabling high concurrency and throughput.
Thread-per-Request Model with Virtual Threads?
Virtual threads should not be pooled; they are cheap, created on-demand for short-lived tasks, and make the thread-per-request model efficient and practical in Java.
More on Virtual Threads are in the following articles: How I Spun Up 5 Million Virtual Threads Without Stalling The JVM.