Modern applications often need to do more than one thing at the same time.

A web server may need to handle multiple users. An application might download files while processing data. A backend service may need to call several APIs without making the user wait unnecessarily.

This is where Java concurrency becomes important.

Java provides several tools for writing concurrent programs, including:

Threads
Runnable and Callable
ExecutorService
Thread pools
Future
CompletableFuture
Synchronization
Concurrent collections

But understanding when to use each one can be confusing at first.

In this beginner-friendly guide, we’ll build the concepts step by step and understand how Threads, Executors, and CompletableFuture work together.

What Is Concurrency?

Concurrency means dealing with multiple tasks during overlapping periods of time.

Imagine an application needs to:

Download a file
Process user data
Send an email

Instead of treating everything as one long sequence:

Download
   ↓
Process
   ↓
Send Email

concurrency allows different tasks to make progress independently:

Download ──────────────→
Process ───────→
Send Email ─────────→

The exact execution depends on the available threads and system resources.

Concurrency vs Parallelism

These terms are related but not identical.

Concurrency

Multiple tasks are being managed or progressed during overlapping periods.

Parallelism

Multiple tasks are actually executing at the same time on different CPU cores.

Think of it this way:

Concurrency
    ↓
Managing multiple tasks

Parallelism
    ↓
Executing multiple tasks simultaneously

A concurrent application isn’t necessarily executing every task simultaneously.

Why Do We Need Concurrency?

A single-threaded application might look like:

Task A
  ↓
Task B
  ↓
Task C
  ↓
Task D

If Task B takes a long time, everything after it waits.

With concurrency:

        ┌── Task A
        │
Thread ─┼── Task B
        │
        └── Task C

Different tasks can make progress without unnecessarily blocking each other.

Concurrency is especially useful for:

Web servers
Database operations
Network requests
File processing
Background jobs
Batch processing
Asynchronous workflows

What Is a Thread?

A thread is a unit of execution within a program.

A Java application starts with a main thread.

For example:

public class Main {

    public static void main(String[] args) {

        System.out.println(
            "Main thread running"
        );
    }
}

The main() method executes on the main thread.

You can create another thread when you need independent execution.

Creating a Thread

One simple approach is:

Thread thread = new Thread(() -> {

    System.out.println(
        "Worker thread running"
    );
});

thread.start();

The important part is:

thread.start();

Not:

thread.run();

`start()` vs `run()`

This is a common interview question.

When you call:

thread.start();

Java starts a new thread of execution.

When you call:

thread.run();

you’re simply calling the method normally on the current thread.

So:

start()
   ↓
New thread execution

run()
   ↓
Normal method call

Remember:

Use start() when you want a new thread.

Using Runnable

Instead of putting everything directly inside Thread, you can define a Runnable.

Runnable task = () -> {

    System.out.println(
        "Task is running"
    );
};

Thread thread = new Thread(task);

thread.start();

Runnable represents a task that doesn’t return a result.

Its main method is:

void run();

Why Not Create Threads Everywhere?

Imagine a server receives:

10,000 requests

Creating a brand-new thread for every task can be expensive.

Threads consume system resources, and excessive thread creation can lead to:

High memory usage
Scheduling overhead
Too much context switching
Poor performance
Resource exhaustion

Instead, applications commonly use thread pools.

That’s where executors come in.

What Is an Executor?

An executor separates:

Submitting a task

from:

Managing the thread that executes it

Instead of doing:

new Thread(task).start();

you can submit the task to an executor.

ExecutorService executor =
    Executors.newFixedThreadPool(4);

executor.submit(() -> {

    System.out.println(
        "Task running"
    );
});

The executor manages the worker threads.

What Is a Thread Pool?

A thread pool is a collection of reusable worker threads.

For example:

        Executor
            │
    ┌───────┼───────┐
    ↓       ↓       ↓
 Thread  Thread  Thread
   1       2       3

Tasks are submitted to the pool.

Task A ──┐
Task B ──┼──→ Thread Pool
Task C ──┤
Task D ──┘

Available workers execute the tasks.

When a task finishes, the worker can execute another task.

ExecutorService

ExecutorService is one of the most commonly used APIs for managing thread pools.

Example:

ExecutorService executor =
    Executors.newFixedThreadPool(3);

executor.submit(() -> {

    System.out.println(
        "Processing task"
    );
});

executor.shutdown();

The pool has three worker threads.

Why Use ExecutorService?

Using an executor gives you more control over concurrency.

You can:

Reuse threads
Submit tasks
Receive results
Shut down execution
Control the number of workers

Instead of manually managing every thread.

Fixed Thread Pool

A fixed thread pool has a fixed number of worker threads.

ExecutorService executor =
    Executors.newFixedThreadPool(4);

Conceptually:

Thread Pool
 ├── Worker 1
 ├── Worker 2
 ├── Worker 3
 └── Worker 4

If more than four tasks are submitted, additional tasks wait until workers become available.

Single Thread Executor

You can also create an executor with one worker:

ExecutorService executor =
    Executors.newSingleThreadExecutor();

Tasks execute one at a time.

Task A
  ↓
Task B
  ↓
Task C

This can be useful when tasks need sequential execution while still being managed through an executor.

Scheduled Executor

If you need delayed or periodic tasks, Java provides scheduled executors.

For example:

ScheduledExecutorService scheduler =
    Executors.newScheduledThreadPool(2);

You can schedule a task:

scheduler.schedule(
    () -> System.out.println("Hello"),
    5,
    TimeUnit.SECONDS
);

The task runs after the specified delay.

Runnable vs Callable

Runnable is useful when a task doesn’t return a result.

Runnable task = () -> {

    System.out.println("Running");
};

Callable can return a value.

Callable<Integer> task = () -> {

    return 10 + 20;
};

Conceptually:

Runnable
   ↓
Task → no result

Callable
   ↓
Task → result

Future

When you submit a Callable to an executor, you can receive a Future.

ExecutorService executor =
    Executors.newFixedThreadPool(2);

Future<Integer> future =
    executor.submit(() -> {

        return 10 + 20;
    });

You can retrieve the result:

Integer result =
    future.get();

The result will be:

The Problem with Future

Future is useful, but it can become awkward when you need multiple asynchronous operations.

For example:

Future<User> userFuture = ...;
Future<Order> orderFuture = ...;
Future<Payment> paymentFuture = ...;

You may end up calling:

userFuture.get();
orderFuture.get();
paymentFuture.get();

This can lead to blocking and makes complex asynchronous workflows harder to express.

This is where CompletableFuture becomes especially useful.

What Is CompletableFuture?

CompletableFuture represents the result of an asynchronous computation.

It allows you to:

Start asynchronous tasks
Transform results
Combine tasks
Handle errors
Run tasks sequentially
Run tasks independently
Wait for multiple tasks

For example:

CompletableFuture<String> future =
    CompletableFuture.supplyAsync(() -> {

        return "Hello";
    });

You can process the result later.

`runAsync()` vs `supplyAsync()`

CompletableFuture provides two commonly used methods.

`runAsync()`

Use when you don’t need a result.

CompletableFuture<Void> future =
    CompletableFuture.runAsync(() -> {

        System.out.println(
            "Background task"
        );
    });

`supplyAsync()`

Use when you need a result.

CompletableFuture<String> future =
    CompletableFuture.supplyAsync(() -> {

        return "Hello";
    });

Simple rule:

runAsync()
   ↓
No result

supplyAsync()
   ↓
Returns a result

Getting the Result

You can use:

future.join();

or:

future.get();

For example:

CompletableFuture<String> future =
    CompletableFuture.supplyAsync(() ->
        "Hello"
    );

String result =
    future.join();

join() waits for completion and throws unchecked completion exceptions.

get() can throw checked exceptions such as InterruptedException and ExecutionException.

`thenApply()`

thenApply() transforms the result of a completed stage.

For example:

CompletableFuture<String> future =
    CompletableFuture.supplyAsync(() ->
        "oliver"
    );

CompletableFuture<String> result =
    future.thenApply(
        name -> name.toUpperCase()
    );

The flow is:

"oliver"
   ↓
thenApply()
   ↓
"OLIVER"

Conceptually:

Input
 ↓
Transform
 ↓
Output

`thenAccept()`

Use thenAccept() when you want to consume the result but don’t need to return another value.

CompletableFuture
    .supplyAsync(() -> "Hello")
    .thenAccept(
        message ->
            System.out.println(message)
    );

The flow is:

Task
 ↓
Result
 ↓
Consume

`thenRun()`

thenRun() runs another action after the previous stage completes, but it doesn’t receive the previous result.

CompletableFuture
    .supplyAsync(() -> "Hello")
    .thenRun(() ->
        System.out.println(
            "Task completed"
        )
    );

`thenApply()` vs `thenAccept()` vs `thenRun()`

An easy way to remember them:

thenApply()
    ↓
Result → New result

thenAccept()
    ↓
Result → Action

thenRun()
    ↓
Completion → Action

For example:

thenApply(x -> x * 2)

transforms a value.

thenAccept(x -> print(x))

consumes a value.

thenRun(() -> cleanup())

runs an action without needing the previous result.

Chaining CompletableFuture

One of the biggest benefits of CompletableFuture is chaining.

For example:

CompletableFuture
    .supplyAsync(() -> getUser())
    .thenApply(user ->
        getUserName(user)
    )
    .thenApply(name ->
        name.toUpperCase()
    );

The flow becomes:

Get User
   ↓
Get Name
   ↓
Convert to Uppercase

This can be much cleaner than deeply nested callbacks.

`thenCompose()`

Sometimes one asynchronous operation starts another asynchronous operation.

For example:

CompletableFuture<User> user =
    getUserAsync();

Then you want:

User
 ↓
Get Orders Async
 ↓
Orders

You can use thenCompose():

CompletableFuture<List<Order>> orders =
    getUserAsync()
        .thenCompose(
            user -> getOrdersAsync(user)
        );

thenCompose() is useful when the next operation itself returns a CompletableFuture.

`thenApply()` vs `thenCompose()`

This is another common interview topic.

`thenApply()`

Use when the function returns a normal value.

future.thenApply(
    value -> transform(value)
);

Conceptually:

Future<T>
   ↓
T → R
   ↓
Future<R>

`thenCompose()`

Use when the function returns another CompletableFuture.

future.thenCompose(
    value -> asyncOperation(value)
);

Conceptually:

Future<T>
   ↓
T → Future<R>
   ↓
Future<R>

A simple rule:

Use thenCompose() to flatten dependent asynchronous operations.

Running Independent Tasks in Parallel

Suppose you need to fetch:

User
Orders
Recommendations

These operations don’t depend on each other.

You can start them independently:

CompletableFuture<User> user =
    getUserAsync();

CompletableFuture<List<Order>> orders =
    getOrdersAsync();

CompletableFuture<List<Product>> products =
    getRecommendationsAsync();

They can make progress concurrently.

Then you can combine their results.

`thenCombine()`

thenCombine() combines two independent CompletableFutures.

For example:

CompletableFuture<User> user =
    getUserAsync();

CompletableFuture<List<Order>> orders =
    getOrdersAsync();

CompletableFuture<String> result =
    user.thenCombine(
        orders,
        (u, o) ->
            u.getName()
            + " has "
            + o.size()
            + " orders"
    );

Conceptually:

User ───────┐
            ├──→ Combine → Result
Orders ─────┘

`CompletableFuture.allOf()`

What if you have several asynchronous tasks?

You can use:

CompletableFuture.allOf(
    future1,
    future2,
    future3
);

For example:

CompletableFuture<String> user =
    getUserAsync();

CompletableFuture<String> orders =
    getOrdersAsync();

CompletableFuture<String> products =
    getProductsAsync();

CompletableFuture<Void> all =
    CompletableFuture.allOf(
        user,
        orders,
        products
    );

allOf() completes when all supplied futures complete.

`anyOf()`

Sometimes you only care about whichever task finishes first.

Use:

CompletableFuture.anyOf(
    future1,
    future2,
    future3
);

Conceptually:

Task A ────────→
Task B ──→ DONE
Task C ───────────→

        ↓
   First result

This can be useful for race-style workflows, such as trying multiple equivalent services.

Exception Handling

Asynchronous code needs proper error handling.

CompletableFuture provides methods such as:

exceptionally()
handle()
whenComplete()

For example:

CompletableFuture<String> future =
    CompletableFuture.supplyAsync(() -> {

        throw new RuntimeException(
            "Something failed"
        );
    });

future.exceptionally(error -> {

    System.out.println(
        error.getMessage()
    );

    return "Fallback";
});

`exceptionally()`

exceptionally() lets you provide a fallback value when a stage fails.

CompletableFuture<String> future =
    getDataAsync()
        .exceptionally(error ->
            "Default Data"
        );

Conceptually:

Success
  ↓
Result

Failure
  ↓
Fallback

`handle()`

handle() receives both the result and the error.

future.handle(
    (result, error) -> {

        if (error != null) {
            return "Fallback";
        }

        return result;
    }
);

This is useful when you want to handle both success and failure in one place.

`whenComplete()`

whenComplete() is useful when you want to perform an action after completion without necessarily changing the result.

For example:

future.whenComplete(
    (result, error) -> {

        if (error != null) {
            logError(error);
        } else {
            logResult(result);
        }
    }
);

This is commonly useful for logging, metrics, or cleanup.

CompletableFuture and Custom Executors

By default, many async methods use the common ForkJoinPool.

But you can provide your own executor.

For example:

ExecutorService executor =
    Executors.newFixedThreadPool(4);

CompletableFuture<String> future =
    CompletableFuture.supplyAsync(
        () -> fetchData(),
        executor
    );

This can be useful when you need control over the execution environment.

Why Custom Executors Matter

Imagine your application performs:

Database Calls
External API Calls
CPU-heavy Calculations

Putting unrelated workloads into the same executor can create contention.

You might use separate executors for different workloads when appropriate:

I/O Tasks
   ↓
I/O Executor

CPU Tasks
   ↓
CPU Executor

The exact design depends on the application.

Virtual Threads and Java Concurrency

Modern Java also provides virtual threads.

Virtual threads are lightweight threads managed by the JVM and are especially useful for high-concurrency, I/O-bound workloads.

For example:

Thread.startVirtualThread(() -> {

    processRequest();

});

Or with an executor:

try (ExecutorService executor =
        Executors.newVirtualThreadPerTaskExecutor()) {

    executor.submit(() -> {
        processRequest();
    });
}

Virtual threads don’t replace every concurrency mechanism.

They are particularly useful when you want a straightforward thread-per-task programming model for workloads that spend significant time waiting on I/O.

Threads vs Executors vs CompletableFuture

Now let’s compare the three.

Feature	Thread	ExecutorService	CompletableFuture
Basic execution	Yes	Yes	Yes
Thread management	Manual	Managed	Usually delegated
Thread reuse	No	Yes	Depends on executor
Return result	No direct result	Yes with `Future`	Yes
Chaining	No	Limited	Excellent
Combining tasks	Manual	Manual	Built-in
Error handling	Manual	Future/exceptions	Built-in stages
Best for	Simple low-level tasks	Managing task execution	Async workflows

A Simple Progression

You can think about Java concurrency like this:

Thread
  ↓
"Run this task"

ExecutorService
  ↓
"Manage these tasks and workers"

CompletableFuture
  ↓
"Build an asynchronous workflow"

Each solves a slightly different problem.

Real-World Example: Order Processing

Imagine an e-commerce application receives an order.

It needs to:

1. Validate order
2. Process payment
3. Update inventory
4. Send notification

Some operations may depend on others.

For example:

Validate
   ↓
Payment
   ↓
Inventory
   ↓
Notification

But some independent operations can potentially run concurrently.

For example:

Payment ──────┐
              ├──→ Final Response
Inventory ────┘

CompletableFuture can help model these asynchronous workflows.

Example with CompletableFuture

Suppose:

CompletableFuture<Payment> payment =
    processPaymentAsync(order);

CompletableFuture<Inventory> inventory =
    updateInventoryAsync(order);

Then:

CompletableFuture<Result> result =
    payment.thenCombine(
        inventory,
        (paymentResult,
         inventoryResult) ->
            createResult(
                paymentResult,
                inventoryResult
            )
    );

This expresses the relationship clearly:

Payment ───────┐
               ├──→ Create Result
Inventory ─────┘

Shared Data and Thread Safety

Concurrency introduces another important problem:

What happens when multiple threads access the same data?

Consider:

int counter = 0;

If multiple threads execute:

counter++;

you may get unexpected results because the operation involves multiple steps and isn’t automatically an atomic read-modify-write operation.

This is a race condition.

Synchronization

Java provides synchronization mechanisms.

For example:

public synchronized void increment() {

    counter++;
}

This can prevent multiple threads from entering that method simultaneously for the same object monitor.

But synchronization should be used thoughtfully.

Excessive locking can reduce concurrency and make code harder to reason about.

Atomic Classes

For simple shared counters, Java provides atomic classes.

For example:

AtomicInteger counter =
    new AtomicInteger(0);

Then:

counter.incrementAndGet();

Atomic classes can provide thread-safe operations without manually synchronizing every operation.

Concurrent Collections

Regular collections aren’t automatically safe for concurrent modification.

Java provides concurrent collections such as:

ConcurrentHashMap
CopyOnWriteArrayList
BlockingQueue

For example:

ConcurrentHashMap<String, Integer>
    cache =
        new ConcurrentHashMap<>();

These collections are designed for particular concurrent access patterns.

Race Conditions

A race condition happens when the result depends on the timing or ordering of concurrent operations.

For example:

Thread A → Read value: 10
Thread B → Read value: 10
Thread A → Write 11
Thread B → Write 11

You might expect:

but get:

This is why shared mutable state must be handled carefully.

Deadlocks

Another concurrency problem is a deadlock.

Imagine:

Thread A
   ↓
Locks Resource 1
   ↓
Waits for Resource 2

Thread B
   ↓
Locks Resource 2
   ↓
Waits for Resource 1

Neither can continue.

A waits for B
B waits for A

This can freeze part of an application.

Avoid unnecessary locking and establish consistent lock-ordering strategies when multiple locks are required.

Blocking vs Non-Blocking

This distinction is important.

A blocking operation makes the current thread wait.

For example:

String result =
    future.get();

The calling thread waits until the future completes.

Asynchronous chaining can avoid explicitly blocking the current thread:

future.thenApply(
    value -> transform(value)
);

However, asynchronous code doesn’t mean “nothing ever waits.”

Underlying operations can still block depending on the APIs being used.

Don’t Use Async for Everything

A common beginner mistake is assuming:

“More threads = faster application.”

That’s not true.

Creating too much concurrency can cause:

CPU contention
Memory pressure
Thread overhead
Database connection exhaustion
More context switching
Harder debugging

Concurrency should be used where it solves a real problem.

Choosing the Right Tool

Here’s a practical guide.

Use `Thread` When:

You need low-level thread control
You’re learning thread fundamentals
You have a simple specialized use case

For application-level task management, higher-level abstractions are usually preferable.

Use `ExecutorService` When:

You need a controlled pool of workers
You have many tasks
You want task submission and result handling
You want control over execution resources

Use `CompletableFuture` When:

You have asynchronous workflows
Tasks need to be chained
Independent tasks need to be combined
You need asynchronous error handling
You want to compose multiple operations

Use Virtual Threads When:

You have very high concurrency
Tasks are primarily I/O-bound
A straightforward thread-per-task model fits your application
You want to take advantage of modern Java concurrency features

Best Practices

Prefer Higher-Level Concurrency APIs

Don’t manually create threads when an executor or another suitable abstraction solves the problem better.

Keep Tasks Small and Focused

A task should have a clear responsibility.

Avoid Shared Mutable State

The less state threads share, the fewer synchronization problems you’ll have.

Use Thread-Safe Collections When Needed

Choose collections designed for concurrent access rather than synchronizing everything manually.

Don’t Block Unnecessarily

Avoid calling blocking methods inside asynchronous workflows when you don’t need to.

Handle Exceptions

Asynchronous exceptions can be easy to miss.

Always design a clear failure strategy.

Shut Down Executors

For executor services you own, make sure they are properly shut down.

executor.shutdown();

Measure Before Optimizing

Concurrency can improve performance, but it can also make a system more complex.

Benchmark real workloads before making major architectural decisions.

Common Interview Questions

What is the difference between concurrency and parallelism?

Concurrency is about managing multiple tasks that overlap in progress; parallelism is about executing multiple tasks simultaneously.

What is the difference between `start()` and `run()`?

start() starts a new thread, while run() is a normal method call when invoked directly.

Why use ExecutorService?

It manages worker threads and task execution instead of requiring manual thread management.

What is the difference between Runnable and Callable?

Runnable doesn’t return a result, while Callable can return a result and throw checked exceptions.

What is CompletableFuture?

It represents the result of an asynchronous computation and provides APIs for chaining, combining, and handling asynchronous operations.

`thenApply()` vs `thenCompose()`?

thenApply() transforms a result, while thenCompose() chains another asynchronous operation and avoids nested futures.

`thenApply()` vs `thenAccept()`?

thenApply() produces another result; thenAccept() consumes the result without producing another value.

What is a race condition?

A race condition occurs when concurrent operations access shared state and the result depends on their timing or ordering.

What is a deadlock?

A deadlock occurs when threads wait indefinitely for resources held by each other.

Final Thoughts

Java concurrency can seem complicated because there are many APIs, but the core ideas are easier to understand when you learn them in order.

Start with:

Threads
   ↓
Runnable / Callable
   ↓
ExecutorService
   ↓
Future
   ↓
CompletableFuture

Then learn:

Synchronization
Atomic Classes
Concurrent Collections
Virtual Threads

The most important distinction to remember is:

Thread
    ↓
Basic unit of execution

ExecutorService
    ↓
Manages task execution and worker threads

CompletableFuture
    ↓
Builds and composes asynchronous workflows

Once you understand these concepts, you’ll be much better prepared to build Java applications that handle multiple tasks efficiently.

And remember:

Good concurrency isn’t about creating as many threads as possible. It’s about using the right execution model for the workload.

Start simple, understand how tasks interact, minimize shared state, and introduce concurrency where it provides a real benefit.

Java Concurrency: Threads, Executors, and CompletableFuture

What Is Concurrency?

Concurrency vs Parallelism

Concurrency

Parallelism

Why Do We Need Concurrency?

What Is a Thread?

Creating a Thread

start() vs run()

Using Runnable

Why Not Create Threads Everywhere?

What Is an Executor?

What Is a Thread Pool?

ExecutorService

Why Use ExecutorService?

Fixed Thread Pool

Single Thread Executor

Scheduled Executor

Runnable vs Callable

Future

The Problem with Future

What Is CompletableFuture?

runAsync() vs supplyAsync()

runAsync()

supplyAsync()

Getting the Result

thenApply()

thenAccept()

thenRun()

thenApply() vs thenAccept() vs thenRun()

Chaining CompletableFuture

thenCompose()

thenApply() vs thenCompose()

thenApply()

thenCompose()

Running Independent Tasks in Parallel

thenCombine()

CompletableFuture.allOf()

anyOf()

Exception Handling

exceptionally()

handle()

whenComplete()

CompletableFuture and Custom Executors

Why Custom Executors Matter

Virtual Threads and Java Concurrency

Threads vs Executors vs CompletableFuture

A Simple Progression

Real-World Example: Order Processing

Example with CompletableFuture

Shared Data and Thread Safety

Synchronization

Atomic Classes

Concurrent Collections

Race Conditions

Deadlocks

Blocking vs Non-Blocking

Don’t Use Async for Everything

Choosing the Right Tool

Use Thread When:

Use ExecutorService When:

Use CompletableFuture When:

Use Virtual Threads When:

Best Practices

Prefer Higher-Level Concurrency APIs

Keep Tasks Small and Focused

Avoid Shared Mutable State

Use Thread-Safe Collections When Needed

Don’t Block Unnecessarily

Handle Exceptions

Shut Down Executors

Measure Before Optimizing

Common Interview Questions

What is the difference between concurrency and parallelism?

What is the difference between start() and run()?

Why use ExecutorService?

What is the difference between Runnable and Callable?

What is CompletableFuture?

thenApply() vs thenCompose()?

thenApply() vs thenAccept()?

`start()` vs `run()`

`runAsync()` vs `supplyAsync()`

`runAsync()`

`supplyAsync()`

`thenApply()`

`thenAccept()`

`thenRun()`

`thenApply()` vs `thenAccept()` vs `thenRun()`

`thenCompose()`

`thenApply()` vs `thenCompose()`

`thenApply()`

`thenCompose()`

`thenCombine()`

`CompletableFuture.allOf()`

`anyOf()`

`exceptionally()`

`handle()`

`whenComplete()`

Use `Thread` When:

Use `ExecutorService` When:

Use `CompletableFuture` When:

What is the difference between `start()` and `run()`?

`thenApply()` vs `thenCompose()`?

`thenApply()` vs `thenAccept()`?