Using Project Loom Virtual Threads in Spring Boot: Setup, Code Samples, and Performance Testing

In this tutorial we explore how to leverage Project Loom virtual threads within a Spring Boot application and evaluate their performance using JMeter load testing.

Virtual threads are part of Project Loom and are not intended to accelerate memory‑bound operations such as parallel streams; their goal is to increase application throughput by efficiently utilizing CPU resources.

We start by configuring the Maven <project>... file to use Java 20, Tomcat 11.0.0‑M4, and include dependencies such as Spring Data JPA, Commons Lang3, MySQL connector, and Lombok.

Because Project Loom is still in preview, the Maven compiler arguments enable the preview feature ( --enable-preview ) and set the source and target compatibility to Java 20.

The Spring Boot main class ( VirtualthreadApplication ) is annotated with @SpringBootApplication and @Slf4j . A @Bean method configures Tomcat to use Executors.newVirtualThreadPerTaskExecutor() so that each request can run on a virtual thread.

A simple REST controller ( HomeController ) provides two endpoints: GET /thread which sleeps for one second and returns all Product entities, and POST /save which creates and saves 1,000 random Product records.

The Product entity is a JPA @Entity with fields id , productName , and price , and ProductRepository extends JpaRepository<Product, Long> .

The application.yaml configures a MySQL datasource, Hikari connection pool, Flyway, and JPA settings.

We first run the application with the virtual‑thread bean commented out, which executes on regular OS threads. Using JMeter we generate 1,000 concurrent GET requests over a 3‑second ramp‑up and observe response times climbing from ~3.6 s to >5.2 s once the Tomcat thread pool is saturated.

Next we enable the virtual‑thread bean, rerun the same JMeter test, and see response times stay around 1 s (occasionally up to 1.4 s) even under 1,000 concurrent requests, demonstrating a dramatic improvement in throughput.

The results indicate that virtual threads allow the application to better exploit CPU capacity, offering higher concurrency without the complexity of reactive programming.

In summary, adopting Project Loom virtual threads can significantly increase the number of simultaneous users an application can serve while keeping response times low, making it a compelling alternative to rewriting code for reactive frameworks.