Most beginners understand “threads”, but they struggle to visualize how multithreading works in Spring Boot.It goes deeper into why, how, internals, threading concepts, performance behavior, and production considerations. Why Do We Need Multi-Threading in Spring Boot? In a typical Spring Boot application, each incoming HTTP request is handled by a Tomcat worker thread.This thread each incoming HTTP request is handled by a Tomcat worker thread executes business logic
calls other services
queries database
formats response executes business logic calls other services queries database formats response Everything happens inside one thread unless you explicitly decide to go async. inside one thread This becomes a problem when your request needs to perform slow operations, such as slow operations External REST API calls
Long database queries
File processing
Calling 3+ microservices
Long computations
Report generation External REST API calls Long database queries File processing Calling 3+ microservices Long computations Report generation The Tomcat thread is blocked → slow API → low throughput. Doing them one-by-one makes your API slow. one-by-one Sequential Execution = Slow Task A → Task B → Task C  
Total time = A + B + C Task A → Task B → Task C  
Total time = A + B + C But many of these tasks can run in parallel. in parallel Parallel Execution = FAST Parallel Execution = FAST Task A  
Task B  
Task C  
(run at the same time) Task A  
Task B  
Task C  
(run at the same time) Imagine a Real Story Imagine a Real Story Your API needs to gather user information Profile from User Service (takes 2 sec)
Orders from Order Service (takes 3 sec)
Recommendations from Recommendation Service (takes 4 sec) Profile from User Service (takes 2 sec) Orders from Order Service (takes 3 sec) Recommendations from Recommendation Service (takes 4 sec) If you do this sequentially 2 + 3 + 4 = 9 seconds 2 + 3 + 4 = 9 seconds Users will assume your API is broken. But notice these calls have no dependency on each other. these calls have no dependency on each other So, they can run in parallel in parallel Run all 3 calls together → total time = 4 sec (longest task) Run all 3 calls together → total time = 4 sec (longest task) This is exactly what ExecutorService + CompletableFuture helps you achieve. ExecutorService + CompletableFuture What Are ExecutorService & CompletableFuture? ExecutorService ExecutorService Think of it like a worker team. worker team You assign tasks → team executes them in parallel.
You control number of workers.
Instead of creating threads manually — you use this service. You assign tasks → team executes them in parallel. You control number of workers. Instead of creating threads manually — you use this service. CompletableFuture CompletableFuture A Future on steroids Future on steroids Runs async code without blocking.
Can combine results of multiple tasks.
Can run tasks in parallel and wait for all to finish.
Has clean API.supplyAsync(), .runAsync(), .thenApply(), .allOf(), etc. Runs async code without blocking. Can combine results of multiple tasks. Can run tasks in parallel and wait for all to finish. Has clean API.supplyAsync(), .runAsync(), .thenApply(), .allOf(), etc. .supplyAsync(), .runAsync(), .thenApply(), .allOf(), Visual Explanation — How it Works Visual Explanation — How it Works Without Parallelism (Sequential) Without Parallelism (Sequential) [API Call]
     |
     |--> Task 1 (3 sec)
     |--> Task 2 (2 sec)
     |--> Task 3 (5 sec)
Total = 10 seconds [API Call]
     |
     |--> Task 1 (3 sec)
     |--> Task 2 (2 sec)
     |--> Task 3 (5 sec)
Total = 10 seconds With Multithreading (Parallel) [API Call]
     |  
     |--> Task 1 (3 sec)
     |--> Task 2 (2 sec)
     |--> Task 3 (5 sec)
All run at same time  
Total = 5 seconds (longest task) [API Call]
     |  
     |--> Task 1 (3 sec)
     |--> Task 2 (2 sec)
     |--> Task 3 (5 sec)
All run at same time  
Total = 5 seconds (longest task) Architecture Diagram How Multi-Threading Actually Works Internally How Multi-Threading Actually Works Internally Let’s break this down in extremely simple terms. Step 1: Spring Boot receives a request Step 1: Spring Boot receives a request A Tomcat thread (say Thread #27) picks it up. Step 2: Tomcat thread delegates async tasks to ExecutorService Step 2: Tomcat thread delegates async tasks to ExecutorService ExecutorService is a thread pool. thread pool Think of it like “Here are 5 workers (threads). They will do tasks for you.” “Here are 5 workers (threads). They will do tasks for you.” You submit tasks: executor.submit(taskA)
executor.submit(taskB)
executor.submit(taskC) executor.submit(taskA)
executor.submit(taskB)
executor.submit(taskC) Now 3 worker threads run tasks in parallel. Tomcat thread is free to do other work. Tomcat thread is free Step 3: CompletableFuture wraps tasks to run async Step 3: CompletableFuture wraps tasks to run async CompletableFuture is like a promise You start a task
It runs in background
You get the result later You start a task It runs in background You get the result later So, CompletableFuture<String> orders = service.fetchOrders(); CompletableFuture<String> orders = service.fetchOrders(); ...means“Start task orders now and return response immediately.” “Start task orders now and return response immediately.” Step 4: allOf() waits until all threads complete Step 4: allOf() waits until all threads complete allOf() This is a synchronization point CompletableFuture.allOf(orders, payments, shipment).join(); CompletableFuture.allOf(orders, payments, shipment).join(); This says“Combine results only when ALL futures have completed.” “Combine results only when ALL futures have completed.” Step 5: Tomcat thread collects results and sends response Step 5: Tomcat thread collects results and sends response By the time Tomcat thread gathers results, tasks are already done. Result → Faster APIs
No blocking
Better scalability Faster APIs No blocking Better scalability Difference Between Thread, ExecutorService & CompletableFuture (Very Clear) Difference Between Thread, ExecutorService & CompletableFuture (Very Clear) Concept

Meaning

Analogy



Thread

Lowest unit of execution

One worker



ExecutorService

A pool of reusable threads

A team of workers



CompletableFuture

Async task handler, easy API

A promise that work will finish Concept

Meaning

Analogy



Thread

Lowest unit of execution

One worker



ExecutorService

A pool of reusable threads

A team of workers



CompletableFuture

Async task handler, easy API

A promise that work will finish Concept

Meaning

Analogy Concept Concept Meaning Meaning Analogy Analogy Thread

Lowest unit of execution

One worker Thread Thread Lowest unit of execution Lowest unit of execution One worker One worker ExecutorService

A pool of reusable threads

A team of workers ExecutorService ExecutorService A pool of reusable threads A pool of reusable threads A team of workers A team of workers CompletableFuture

Async task handler, easy API

A promise that work will finish CompletableFuture CompletableFuture Async task handler, easy API Async task handler, easy API A promise that work will finish A promise that work will finish Why Not Create Threads Manually? Why Not Create Threads Manually? Because manual threads cause: Memory leaks
Too many threads
No lifecycle management
No reuse
No graceful shutdown Memory leaks Too many threads No lifecycle management No reuse No graceful shutdown ExecutorService manages threads properly: Creates fixed number of threads
Reuses them
Avoids overhead
Avoids thread explosion Creates fixed number of threads Reuses them Avoids overhead Avoids thread explosion CompletableFuture adds additional magic: Clean async composition
Exception handling
Chaining
Combining tasks
Running tasks sequentially or parallel Clean async composition Exception handling Chaining Combining tasks Running tasks sequentially or parallel Together → powerful and clean async code. Real Spring Boot Code Real Spring Boot Code Step 1(a): Create Thread Pool Bean Step 1(a): Create Thread Pool Bean @Configuration
public class AsyncConfig {

    @Bean
    public ExecutorService executorService() {
        return Executors.newFixedThreadPool(5);
    }
} @Configuration
public class AsyncConfig {

    @Bean
    public ExecutorService executorService() {
        return Executors.newFixedThreadPool(5);
    }
} Meaning Create a pool of 5 threads.
These threads are reused.
No new threads created each time. Create a pool of 5 threads. These threads are reused. No new threads created each time. This is crucial for performance. Step 1(b): Parallel Tasks Using CompletableFuture Step 1(b): Parallel Tasks Using CompletableFuture return CompletableFuture.supplyAsync(() -> {
    sleep(3000);
    return "Result A";
}, executor); return CompletableFuture.supplyAsync(() -> {
    sleep(3000);
    return "Result A";
}, executor); Breakdown Breakdown supplyAsync = run this function asynchronously
lambda = the task
executor = thread pool on which work runs supplyAsync = run this function asynchronously lambda = the task executor = thread pool on which work runs This ensures your tasks do not run on the main request thread. not Step 2: Service using CompletableFuture Step 2: Service using CompletableFuture @Service
public class AggregationService {

    private final ExecutorService executor;

    public AggregationService(ExecutorService executor) {
        this.executor = executor;
    }

    // Simulate a remote call or IO-bound work
    public CompletableFuture<String> fetchOrders() {
        return CompletableFuture.supplyAsync(() -> {
            sleep(300);
            return "OrdersLoaded";
        }, executor);
    }

    public CompletableFuture<String> fetchPayments() {
        return CompletableFuture.supplyAsync(() -> {
            sleep(250);
            return "PaymentsLoaded";
        }, executor);
    }

    public CompletableFuture<String> fetchShipment() {
        return CompletableFuture.supplyAsync(() -> {
            sleep(500);
            return "ShipmentLoaded";
        }, executor);
    }

    private void sleep(long ms) {
        try {
            TimeUnit.MILLISECONDS.sleep(ms);
        } catch (InterruptedException e) {
            Thread.currentThread().interrupt();
        }
    }
} @Service
public class AggregationService {

    private final ExecutorService executor;

    public AggregationService(ExecutorService executor) {
        this.executor = executor;
    }

    // Simulate a remote call or IO-bound work
    public CompletableFuture<String> fetchOrders() {
        return CompletableFuture.supplyAsync(() -> {
            sleep(300);
            return "OrdersLoaded";
        }, executor);
    }

    public CompletableFuture<String> fetchPayments() {
        return CompletableFuture.supplyAsync(() -> {
            sleep(250);
            return "PaymentsLoaded";
        }, executor);
    }

    public CompletableFuture<String> fetchShipment() {
        return CompletableFuture.supplyAsync(() -> {
            sleep(500);
            return "ShipmentLoaded";
        }, executor);
    }

    private void sleep(long ms) {
        try {
            TimeUnit.MILLISECONDS.sleep(ms);
        } catch (InterruptedException e) {
            Thread.currentThread().interrupt();
        }
    }
} Step 3: Controller — Run all tasks in parallel @RestController
@RequestMapping("/api")
public class AggregationController {

    private final AggregationService service;

    public AggregationController(AggregationService service) {
        this.service = service;
    }

    // Endpoint using CompletableFuture + custom ExecutorService
    @GetMapping("/aggregate")
    public String aggregate() {
        Instant start = Instant.now();

        CompletableFuture<String> orders = service.fetchOrders();
        CompletableFuture<String> payments = service.fetchPayments();
        CompletableFuture<String> shipment = service.fetchShipment();

        // Wait for all to complete
        CompletableFuture.allOf(orders, payments, shipment).join();

        String result = orders.join() + " | " + payments.join() + " | " + shipment.join();

        Instant end = Instant.now();
        long elapsedMs = Duration.between(start, end).toMillis();
        return String.format("result=%s; elapsedMs=%d", result, elapsedMs);
    }} @RestController
@RequestMapping("/api")
public class AggregationController {

    private final AggregationService service;

    public AggregationController(AggregationService service) {
        this.service = service;
    }

    // Endpoint using CompletableFuture + custom ExecutorService
    @GetMapping("/aggregate")
    public String aggregate() {
        Instant start = Instant.now();

        CompletableFuture<String> orders = service.fetchOrders();
        CompletableFuture<String> payments = service.fetchPayments();
        CompletableFuture<String> shipment = service.fetchShipment();

        // Wait for all to complete
        CompletableFuture.allOf(orders, payments, shipment).join();

        String result = orders.join() + " | " + payments.join() + " | " + shipment.join();

        Instant end = Instant.now();
        long elapsedMs = Duration.between(start, end).toMillis();
        return String.format("result=%s; elapsedMs=%d", result, elapsedMs);
    }} Meaning“Wait until all async tasks finish.” “Wait until all async tasks finish.” Then collect results String result = orders.join() + " | " + payments.join() + " | " + shipment.join(); String result = orders.join() + " | " + payments.join() + " | " + shipment.join(); This is done only when all tasks complete. What Happens When You Call / Aggregate? What Happens When You Call / Aggregate? Orders = 3 secPayments = 2 secShipment = 5 sec All run simultaneously. simultaneously Total time = 5 seconds (longest task) Total time = 5 seconds Without parallelism → 3 + 2 + 5 = 10 secondsWith parallelism → only 5 seconds Output Output Performance Comparison Scenario

Execution Time



Sequential Processing

10 sec



Parallel Processing (3 tasks)

4 sec



Parallel + non-blocking I/O

2–3 sec Scenario

Execution Time



Sequential Processing

10 sec



Parallel Processing (3 tasks)

4 sec



Parallel + non-blocking I/O

2–3 sec Scenario

Execution Time Scenario Scenario Execution Time Execution Time Sequential Processing

10 sec Sequential Processing Sequential Processing 10 sec 10 sec Parallel Processing (3 tasks)

4 sec Parallel Processing (3 tasks) Parallel Processing (3 tasks) 4 sec 4 sec Parallel + non-blocking I/O

2–3 sec Parallel + non-blocking I/O Parallel + non-blocking I/O 2–3 sec 2–3 sec This is a 60% to 80% performance boost. 60% to 80% performance boost Real-World Production Scenarios Real-World Production Scenarios Here are real use cases where multi-threading is used in enterprise applications: Aggregating Microservice Results Aggregating Microservice Results User Profile API → 2 sec  
Orders API → 3 sec  
Payments API → 1 sec User Profile API → 2 sec  
Orders API → 3 sec  
Payments API → 1 sec Parallel makes response time 3 seconds instead of 6. Data Engineering Data Engineering Spark-like parallel job in Spring Boot: Parse 1000 files
Process 20 file batches concurrently
Write results to S3 Parse 1000 files Process 20 file batches concurrently Write results to S3 ExecutorService is ideal here. Large Report Generation A PDF report may contain: Summary
Graphs
Tables
Statistics Summary Graphs Tables Statistics Each section can be calculated in parallel. AI/ML Feature Generation Extract: Feature set 1
Feature set 2
Feature set 3 Feature set 1 Feature set 2 Feature set 3 These can run independently → perfect for threads. Sending Multiple Notifications Sending Multiple Notifications Your system triggers: Email
SMS
Push notification Email SMS Push notification All can run asynchronously. Thread Safety Considerations (Important for Interviews) Thread Safety Considerations (Important for Interviews) When using multi-threading Avoid shared mutable state
Use thread-safe collections (ConcurrentHashMap)
Avoid synchronized unless needed
Stateless services are ideal
Be careful with static variables Avoid shared mutable state Use thread-safe collections (ConcurrentHashMap) Avoid synchronized unless needed Stateless services are ideal Be careful with static variables Spring beans are singletons, so ensure they don’t store per-request state. singletons Scaling Considerations Scaling Considerations Thread pool size depends on workload: For CPU-bound tasks For CPU-bound tasks threads = number of CPU cores + 1 threads = number of CPU cores + 1 For IO-bound tasks threads = 2 × cores or even higher threads = 2 × cores or even higher Danger - Too many threads Danger - Too many threads high context switching
OOM (OutOfMemoryError)
slowdown high context switching OOM (OutOfMemoryError) slowdown Always benchmark thread pool sizes. Advantages of Using ExecutorService + CompletableFuture Advantages of Using ExecutorService + CompletableFuture Massive performance improvement → Parallelism reduces wasted time. Massive performance improvement Non-blocking architecture → Allows server to handle more requests. Non-blocking architecture Clear async syntax → Very readable. Clear async syntax Built-in error handling → Computation doesn’t silently fail. Built-in error handling Thread pooling for efficient usage → No thread explosion. Thread pooling for efficient usage Works with Microservice Aggregation pattern → Modern microservices use this everywhere. Works with Microservice Aggregation pattern

Multi-Threading in Spring Boot with ExecutorService & CompletableFuture

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

Spring Boot Audit Logs: Capture Every API Action Without Writing Boilerplate Code

Java bits: 0xFF and 0xFFL

The Noonification: Charting a Path for Global AI Regulation (11/14/2023)

100+ Free Pluralsight Courses to learn Python, Java, and Spring Boot

100 Pieces of Programming Advice from the Book Clean Code by Robert Martin

10 Useful Tools and Libraries for Programmer and IT Professionals

Spring Boot Audit Logs: Capture Every API Action Without Writing Boilerplate Code

Java bits: 0xFF and 0xFFL

The Noonification: Charting a Path for Global AI Regulation (11/14/2023)

100+ Free Pluralsight Courses to learn Python, Java, and Spring Boot

100 Pieces of Programming Advice from the Book Clean Code by Robert Martin

10 Useful Tools and Libraries for Programmer and IT Professionals

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps