Forem: Aswathy Nair

Java Concurrency: ExecutorService, RejectionPolicies & ThreadPools — Part 2

Aswathy Nair — Tue, 19 May 2026 04:58:03 +0000

This post covers thread pools, ExecutorService, rejection policies,
scheduled tasks, thread states, and a ThreadLocal bug.

If you haven't read Part 1,
start here: Java Concurrency: From Threads to Thread Safety — Part 1

ExecutorService

A thread is not free. The JVM allocates a stack for every thread — about 512KB by default.

1000 threads  =  ~500MB  just for stacks
10000 threads =  ~5GB    just for stacks

That is before your objects, your heap, or your application logic gets any memory. On top of that, Linux has a hard limit on threads per process — usually between 1000 and 4000. Cross that line and you get:

java.lang.OutOfMemoryError: unable to create native thread

Your server crashes.

Instead of creating a new thread for every task, keep a fixed pool of threads alive and let tasks queue up.

Raw threads     = hire a new chef per order → restaurant goes bankrupt
ExecutorService = 10 permanent chefs + order queue → scalable

Order comes in → sits in queue → first free chef picks it up → finishes → picks next

Two things to know upfront about this model:

When all threads are busy, tasks wait in a BlockingQueue until a thread frees up
If a thread crashes mid-task, that task is lost by default. Java does not retry. No exception in your logs unless you handle it yourself.

ExecutorService executor = Executors.newFixedThreadPool(3);

for (int i = 0; i < 6; i++) {
    int count = i;
    executor.submit(() -> {
        System.out.println("Task:" + count + " running on: "
                            + Thread.currentThread().getName());
    });
}

executor.shutdown();

Output:

Task:1 running on: pool-1-thread-2
Task:0 running on: pool-1-thread-1
Task:2 running on: pool-1-thread-3
Task:3 running on: pool-1-thread-2
Task:4 running on: pool-1-thread-3
Task:5 running on: pool-1-thread-1

Two things to notice here.

Only three thread names show up — pool-1-thread-1, pool-1-thread-2, pool-1-thread-3. Six tasks, three threads. Each thread picked up two tasks. That is the reuse happening.

Note: Task 0 was submitted first but printed second. Submission order is not execution order. First free thread wins. Not round robin, not ordered. If your business logic needs sequence, use newSingleThreadExecutor.

ThreadPoolExecutor — what is actually running under the hood

All Executors.newXxx() factory methods are wrappers around ThreadPoolExecutor. When you call Executors.newFixedThreadPool(3), Java internally creates:

new ThreadPoolExecutor(
    3,                           // corePoolSize
    3,                           // maximumPoolSize
    0L, TimeUnit.MILLISECONDS,   // keepAliveTime
    new LinkedBlockingQueue<>()  // unbounded queue
);

In production, use ThreadPoolExecutor directly so you control the bounds:

new ThreadPoolExecutor(
    10,                            // core threads — always alive
    100,                           // max threads — ceiling under load
    60L, TimeUnit.SECONDS,         // kill extra threads after idle
    new LinkedBlockingQueue<>(500) // bounded queue — 500 tasks max
);

How task submission works internally

1. Thread available in core pool?      → assign immediately
2. Core pool full, queue not full?     → add to queue
3. Queue full, below max pool size?    → create new thread
4. Queue full, at max pool size?       → REJECTION POLICY triggers

Rejection policies

When the queue is full and the pool is at maximum size, every new submit() triggers the rejection policy.

Policy	What it does
`AbortPolicy`	Throws `RejectedExecutionException` — this is the default
`CallerRunsPolicy`	The calling thread runs the task itself
`DiscardPolicy`	Silently drops the task
`DiscardOldestPolicy`	Drops the oldest queued task, retries the new one

I set up a pool with 2 threads and a queue of 2 to see the default behaviour:

ExecutorService service = new ThreadPoolExecutor(
    2, 2, 0L, TimeUnit.MILLISECONDS,
    new LinkedBlockingQueue<>(2)
);

for (int i = 0; i < 5; i++) {
    service.submit(task);
}

2 threads busy + 2 queue slots full. Task 5 had nowhere to go:

java.util.concurrent.RejectedExecutionException
  rejected from ThreadPoolExecutor
  [Running, pool size = 2, active threads = 2, queued tasks = 2, completed tasks = 0]

That error message is a full status report of what the pool was doing at the moment of rejection.

CallerRunsPolicy

ExecutorService service = new ThreadPoolExecutor(
    2, 2, 0L, TimeUnit.MILLISECONDS,
    new LinkedBlockingQueue<>(2),
    new ThreadPoolExecutor.CallerRunsPolicy()
);

When pool and queue are both full — the thread that called submit() runs the task itself:

Task:0 running on: pool-1-thread-1
Task:4 running on: main             ← main thread ran this one
Task:2 running on: pool-1-thread-1
Task:3 running on: pool-1-thread-1
Task:1 running on: pool-1-thread-2

Main slows down. Pool catches up. No exception, no data loss, self-regulating.

Custom rejection handler

RejectedExecutionHandler handler = (rejectedTask, executor) -> {
    System.out.println("Task rejected: " + rejectedTask.toString());

    // options: dead letter queue, retry, alert ops team
};

 ExecutorService serviceWithHandler = new ThreadPoolExecutor(
                2,                          // core threads
                2,                          // max threads
                0L, TimeUnit.MILLISECONDS,  // keep alive
                new LinkedBlockingQueue<>(2), // bounded queue
                handler                     // your custom handler
        );

In production, a custom handler is almost always the right choice over the built-in policies.

Pitfall #1: DiscardPolicy

DiscardPolicy silently drops tasks with zero noise. No exception, no log, no trace. The task just disappears. Not recommended in production specifically in areas of payment processing, audit logging, archiving etc.,
If you are dropping tasks in production, at minimum log it.

shutdown() vs shutdownNow()

executor.shutdown();
// ✅ Running tasks → complete
// ✅ Queued tasks  → complete
// ❌ New submissions → RejectedExecutionException

Graceful. Finish what is already submitted, close the door to new work.

executor.shutdownNow();
// ✅ Returns list of queued tasks that were NOT run
// ⚠️ Attempts to interrupt running tasks
// ❌ New submissions → RejectedExecutionException

I tried submitting a task after shutdown() to see what happens:

ExecutorService service = Executors.newFixedThreadPool(3);
service.shutdown();
service.submit(() -> System.out.println("Am I running?"));

java.util.concurrent.RejectedExecutionException
  rejected from ThreadPoolExecutor
  [Terminated, pool size = 0, active threads = 0, queued tasks = 0, completed tasks = 0]

Terminated, pool size = 0. The pool was already dead by the time the task hit it.

Pitfall #2: shutdownNow() does not guarantee threads stop

shutdownNow() sends an interrupt signal. A thread only actually stops if it is sleeping (throws InterruptedException) or checks Thread.currentThread().isInterrupted(). A thread doing pure CPU work ignores the signal and keeps running.

Always have a check in place.

executor.shutdown();
if (!executor.awaitTermination(5, TimeUnit.SECONDS)) {
    executor.shutdownNow(); // force if graceful didn't finish in time
}

ThreadPool types

Pool	Threads
`newFixedThreadPool(n)`	Always exactly n // steady load
`newCachedThreadPool`	0 to unlimited // for low volume only
`newSingleThreadExecutor`	Always exactly 1 // Strict sequential order
`newScheduledThreadPool(n)`	Fixed n // Fixed-rate or delayed tasks
`ThreadPoolExecutor` directly	You decide everything // Production — always

Pitfall #3: newCachedThreadPool under load

newCachedThreadPool creates threads on demand and kills them after 60 seconds idle. Useful, but no upper bound.

10000 tasks come in. 10000 threads get created. Same original OOM problem.

The real answer for variable load:

new ThreadPoolExecutor(
    10,   // core — always ready
    100,  // max — ceiling at peak
    60L, TimeUnit.SECONDS,         // kill extras after idle
    new LinkedBlockingQueue<>(500) // bounded — reject rather than OOM
);

Scheduled tasks — scheduleAtFixedRate vs scheduleWithFixedDelay

ScheduledExecutorService scheduler = Executors.newScheduledThreadPool(1);

scheduler.scheduleAtFixedRate(task, 0, 30, TimeUnit.SECONDS);
scheduler.scheduleWithFixedDelay(task, 0, 30, TimeUnit.SECONDS);

If the task takes 10 seconds and the interval is 30 seconds:

scheduleAtFixedRate — fixed clock, ignores task duration:
T=0   task starts ──────── T=10 done
T=30  task starts ──────── T=40 done
T=60  task starts ──────── T=70 done

scheduleWithFixedDelay — gap measured AFTER task completes:
T=0   task starts ──────── T=10 done ── wait 30s ──
T=40  task starts ──────── T=50 done ── wait 30s ──
T=80  task starts

What if the task takes longer than the interval?

Let's take the case where task take more than the expected execution time. With scheduleAtFixedRate, if tasks take 45 seconds, interval 30 seconds

T=0   task starts ──────────────── T=45 done
T=30  should start — waits, does not overlap
T=45  starts immediately after previous finishes

ScheduledThreadPoolExecutor will not start the next run until the current one finishes. No pileup. No second thread spawned. It just runs back to back with no gap.

But with newScheduledThreadPool(n > 1) and multiple slow tasks — pileup can happen. For single recurring jobs, always use newScheduledThreadPool(1).

Stopping a scheduled task after N executions

The core issue: you need a counter inside the lambda to track the executions.

AtomicInteger solves both problems:

AtomicInteger count = new AtomicInteger(0);
// Object reference → effectively final
// incrementAndGet() → atomic via CAS

The lambda needs the ScheduledFuture to cancel itself. But the future is assigned after the lambda is created. AtomicReference fixes this — the lambda captures the box, not what is inside it:

ScheduledExecutorService scheduler = Executors.newScheduledThreadPool(1);
AtomicInteger count = new AtomicInteger(0);
AtomicReference<ScheduledFuture<?>> future = new AtomicReference<>();

future.set(scheduler.scheduleAtFixedRate(() -> {
    System.out.println("Health check: " + LocalDateTime.now());
    if (count.incrementAndGet() >= 5) {
        future.get().cancel(false);
        scheduler.shutdown();
    }
}, 0, 2, TimeUnit.SECONDS));

Output:

Health check: 2026-05-17T15:37:35.753357
Health check: 2026-05-17T15:37:37.748608
Health check: 2026-05-17T15:37:39.748212
Health check: 2026-05-17T15:37:41.748337
Health check: 2026-05-17T15:37:43.746872

Note: cancel(false) means do not interrupt if the task is currently running. cancel(true) sends an interrupt signal to the running task.

Thread states

Every thread in Java is always in one of six states:

NEW            → created, start() not called yet
RUNNABLE       → running or ready to run
BLOCKED        → waiting to acquire a synchronized lock
WAITING        → waiting indefinitely — join(), wait()
TIMED_WAITING  → waiting with a timeout — sleep(n), join(n)
TERMINATED     → done

Check the below code:

Object lock = new Object();

Thread t1 = new Thread(() -> {
    synchronized(lock) {
        try { Thread.sleep(5000); }
        catch (InterruptedException e) {}
    }
});

Thread t2 = new Thread(() -> {
    synchronized(lock) {
        System.out.println("t2 got the lock");
    }
});

t1.start();
Thread.sleep(100); // let t1 grab the lock first
t2.start();
Thread.sleep(200);

System.out.println("t1: " + t1.getState());
System.out.println("t2: " + t2.getState());

Output:

t1: TIMED_WAITING
t2: BLOCKED
t2 got the lock

t1 holds the lock and is sleeping — TIMED_WAITING because sleep() has a timeout.
t2 wants the lock but cannot get it — BLOCKED because the lock is held by t1.

BLOCKED vs WAITING

BLOCKED        → fighting for a lock
                 cause: synchronized contention or deadlock
                 fix: find who holds the lock, reduce contention

WAITING        → waiting for a signal
                 cause: join(), wait(), park()
                 fix: check if the thread it's waiting on is alive

If you see something similar in your application thread dump,

"pool-1-thread-2"
   java.lang.Thread.State: BLOCKED
   waiting to lock <0x000000076b572018>
   held by "pool-1-thread-1"

"pool-1-thread-1"
   java.lang.Thread.State: TIMED_WAITING
   sleeping

Thread-1 sleeping while holding a lock, thread-2 stuck waiting for it.

ThreadLocal

The problem: A web server where each request runs on a thread from a pool. You need to store the current user or request ID so that any method in the call chain can access it, without passing it as a parameter to every method.

A static variable is the obvious first thought, but a strict NO.

ThreadLocal gives each thread its own private copy:

static ThreadLocal<String> requestId = new ThreadLocal<>();

// Thread 1
requestId.set("REQ-001");
requestId.get(); // → REQ-001

// Thread 2
requestId.set("REQ-002");
requestId.get(); // → REQ-002

// Thread 1 again
requestId.get(); // → REQ-001, not REQ-002

No sharing. No synchronization needed. Each thread sees only its own value.

How it works internally

ThreadLocal holds no data. It is just a key.

Every Thread object has a hidden field : ThreadLocalMap —> that belongs to that thread exclusively. The map is created lazily on the first set() call.

When you call set():

public void set(T value) {
    Thread t = Thread.currentThread();   
    ThreadLocalMap map = t.threadLocals; 
    map.set(this, value);               
    // store with ThreadLocal as key
}

When you call get():

public T get() {
    Thread t = Thread.currentThread();   
    ThreadLocalMap map = t.threadLocals; 
    return map.get(this);               
    // look up using ThreadLocal as key
}

Note: Spring uses this pattern heavily — SecurityContextHolder, TransactionSynchronizationManager, RequestContextHolder. One thread per request, one context per thread.

Pitfall #4: The ThreadLocal memory leak

Thread pools reuse threads. A thread that handled Request 1 will handle Request 5000. The thread lives forever, until the pool shuts down.

If you set() a value and never clean it up, that value stays in the thread's map. Two things go wrong:

Memory leak: GC cannot collect it because the thread is alive and holding the reference. Thousands of requests, thousands of stale objects accumulating.

Data leak: The next request on that same thread calls get() without calling set() first — and gets the previous request's value.

I ran this with a single-thread pool:

static ThreadLocal<String> requestId = new ThreadLocal<>();

ExecutorService service = Executors.newFixedThreadPool(1);

// First batch — sets values
for (int i = 0; i < 3; i++) {
    String value = "REQ-00" + (i + 1);
    service.submit(() -> {
        requestId.set(value);
        System.out.println("first call: " + requestId.get());
    });
}

// Second batch — only reads, no set
for (int i = 0; i < 3; i++) {
    service.submit(() -> {
        System.out.println("second call: " + requestId.get());
    });
}

Without remove():

first call: REQ-001
first call: REQ-002
first call: REQ-003
second call: REQ-003
second call: REQ-003
second call: REQ-003

REQ-003 was the last value set by the first batch. The thread went back to the pool with that value still sitting in its map. Every subsequent task that only called get() received stale data from a previous request.

The fix:
With remove() in a finally block:

service.submit(() -> {
    try {
        requestId.set("REQ-001");
        // do work
    } finally {
        requestId.remove(); // always in finally, on the pool thread
    }
});

first call: REQ-001
first call: REQ-002
first call: REQ-003
second call: null
second call: null
second call: null

Note: remove() must be inside the lambda — on the pool thread that actually set the value, otherwise it will be referrring to main thread's map.

What's next?

I will be discussing Java memory model, volatile, CompletableFuture in upcoming posts.

Java Concurrency: From Threads to Thread Safety — Part 1

Aswathy Nair — Mon, 18 May 2026 11:48:10 +0000

I have been spending some time to dig deeper into Java concurrency - threads, synchronization, race conditions.
Most tutorials usually show you how to start a Thread, print "Hello World" which is not how any of this works in production.

This post covers my experiments, traps that I fell into, and what finally clicked - the non-"Hello World" way.

Processes vs. Threads

You can think of a Process as a factory. It has its own walls and its own resources. When you boot up a Java application, the JVM itself is the process.

A Thread is a worker inside your factory. The JVM automatically creates the main thread when your app starts. Every other thread you spawn is born from that main thread. Because all threads share the exact same workspace (the Java Heap memory), they can communicate instantly.

This shared memory is the root cause that makes multithreading dangerous. If one thread reads a value while another thread is halfway through updating it, the data gets corrupted. They don't even need to run at the exact same instant — one thread just needs to get in between another's read and write.

What threads share vs What they own

Shared between all threads in a process:

Heap memory — all your new SomeObject() calls
Static variables — one copy, every thread sees it
Class bytecode — the compiled .class files

Private to each thread:

Its own stack — local variables, method parameters, return addresses
Program counter — which line is this thread currently executing

Creating a thread: The Two Ways

If you want to hire a background worker in Java, there are two ways to do it.

Way 1: Extend the Thread Class

class MyWorker extends Thread {
    @Override
    public void run() {
        System.out.println("Running on: " + Thread.currentThread().getName());
    }
}
new MyWorker().start();

Way 2: Implement Runnable

Runnable is an interface with a single run() method.

Runnable task = () -> {
    System.out.println("Running on: " + Thread.currentThread().getName());
};
new Thread(task).start();

Note: Implementing Runnable keeps your class free to extend something else. In real codebases, always prefer Runnable.

Pitfall #1

Observe the below code:

new Thread(task).run();    // Looks right. Completely wrong.
new Thread(task).start();  // What you actually want.

I ran this to see what happens:

Runnable task = () -> {
    System.out.println("Running on: " + Thread.currentThread().getName());
};

System.out.println("--- calling run() ---");
new Thread(task).run();

System.out.println("--- calling start() ---");
new Thread(task).start();

Output:

    --- calling run() ---
    Running on: main
    --- calling start() ---
    Running on: Thread-1

run() is just a regular method call. No new thread is born. The main thread itself jumps into run() and executes it. You never left main. Nothing concurrent happened.

start() actually tells the JVM — spin up a new thread, give it a stack, and let it run. That's when you see Thread-1 in the output.

Calling run() instead of start() is the worst kind of bug because it throws no errors, the code executes, but your application stays single-threaded.

The Static Variable and `join()`

Runnable has a fundamental flaw - run() method returns void. It behaves like fire and forget.

The hack was to use a shared static variable, whenever a value needs to be returned.

static int result = 0;

public static void main(String[] args) {
    Runnable task = () -> { result = 10 + 10; };
    new Thread(task).start();

    System.out.println(result); // What does this print?
}

If you run this, it will almost always print 0.
Because the main thread is fast. It starts the background worker, and then immediately races to the next line and prints result before the background worker even computes.

To fix this, we have to force the main thread to wait using .join().

    Thread t1 = new Thread(task);
    t1.start();
    t1.join(); // Tells the main thread: Stop here until t1 is completely dead.
    System.out.println(result); // Now prints 20

Pitfall #2: The Race Condition

The static variable combined with .join() works for one thread, but it falls apart in production code.
If you have two threads writing to that shared result variable at the same time, their data overwrites each other unpredictably. The output will change from run to run making it difficult to debug.

Callable & FutureTask

Static variable hack is so unpredictable, Java introduced Callable.

It is exactly like Runnable, but it returns a value and can throw exceptions.

But there is a catch: Thread doesn't accept Callable directly. The compiler will throw an error if you try new Thread(myCallable).

So Java has FutureTask — a wrapper that accepts a Callable and is itself Runnable, so Thread can take it:

    Callable<String> task = () -> {
        return "Result from: " + Thread.currentThread().getName();
    };

    FutureTask<String> futureTask = new FutureTask<>(task);
    new Thread(futureTask).start();

    System.out.println(futureTask.get()); // blocks until result is ready

ExecutorService & Future

Above code works fine. But we are creating a new Thread for every task. In real production case, this can easily spin up thousands of threads and result in OutOfMemoryError.

To put a check on this, a manager for thread creation is needed: an ExecutorService.

When you submit a Callable to a thread pool, the manager gives you back a Future.

A Future is basically a promise — the worker is on it, and the result will show up here when it's done. Main thread doesn't freeze, it just calls future.get() when it actually needs the value.

// 1. Initialize the Manager (A pool of 10 workers)
ExecutorService executorService = Executors.newFixedThreadPool(10);

// 2. Submit the task
Future<String> future = executorService.submit(myCallable);

// 3. Check the result
System.out.println(future.get());

executorService.shutdown();

Pitfall #3

The .get() method is blocking. When your main thread hits future.get(), it pauses and waits for the background worker to populate the box.

If that background worker gets stuck in an infinite loop, the main thread waits forever. Your application freezes. In production, never call .get() without a timeout.

try {
    System.out.println(future.get(3, TimeUnit.SECONDS));
} catch (TimeoutException e) {

    System.out.println("Task took too long!");
    future.cancel(true); // <--- Kill the zombie worker
}

Note: cancel(true). If you give up waiting, tell the worker to stop. Otherwise, it stays alive in the background keeping CPU running forever as a "zombie worker".

Shared State

Even with thread pools and futures, what happens when all threads try to access the exact same data?

Imagine a simple Bank Account:

public class BankAccount {
    private int balance = 0;

    public void deposit() {
        balance ++; 
    }

    public int getBalance() {
        return balance;
    }
}

Let's use our ExecutorService to submit exactly 10000 tasks. Every single task will simply call deposit() on the exact same bank account.

ExecutorService service = Executors.newFixedThreadPool(10);
BankAccount bankAccount = new BankAccount();

// Submit 10,000 deposit tasks to the pool
for (int i = 0; i < 10000; i++) {
    service.submit(() -> bankAccount.deposit());
}

// wait for the workers to finish
service.shutdown(); 
service.awaitTermination(5, TimeUnit.SECONDS);

System.out.println("Final balance: " + bankAccount.getBalance());

10000 deposits should equal a final balance of 10000. But if you run this code, you will get 9998. Or 9991. Or 9997.

Pitfall #4

For us, balance++ is one step. But to a CPU, it is three:

Read the current balance.
Add 1 to it.
Write the new value back.

For example: If Thread A reads the balance at 5000, and Thread B reads it before A writes back, they both see 5000. Both add 1, both write 5001. Two deposits, one update lost.

Fixing the Race Condition

First thing to try is to use synchronized.

public synchronized void deposit() {
    balance ++;
}

When you add synchronized to a method, Java automatically uses the object itself (in this case, your bankAccount instance) as a lock.

    * Thread 1 grabs the lock, runs the method.
    * Threads 2 through 10000 hit the locked door and OS put all those to sleep state (`BLOCKED`)
    * Thread 1 finishes, returns the lock, and wakes up Thread 2.
    * Repeat 10000 times.

synchronized works fine until many threads are constantly fighting for the same lock. When contention is high, thousands of threads hitting the same method, the constant blocking and waking becomes the bottleneck and you can end up slower than a single thread. That's when you look for alternatives.

Lock-Free Concurrency (Atomics)

Instead of locks, we can use hardware-level instructions. Modern CPUs have a feature called Compare-And-Swap (CAS).
It says:
Update a value only if it has not been changed by another thread.

In Java, we use AtomicInteger which is built on CAS mechanism. Here is the code:

public class BankAccount {
    private AtomicInteger balance = new AtomicInteger(0);

    // No synchronized keyword needed!
    public void deposit() {
        balance.incrementAndGet();
    }

    public int getBalance() {
        return balance.get();
    }
}

If you run 10000 threads against this, your balance prints 10000 every single time. No locks, no blocking. But it's not magic — see the note below

Note: CAS isn't free. Under the hood, if the update fails, the thread retries in a loop — it doesn't sleep, it spins. With few threads this is fast. With thousands of threads all spinning on the same value, you're burning CPU on retries. synchronized at least puts threads to sleep. Pick based on your contention level.

What's Next?

We will be discussing more on CompletableFuture, ConcurrentHashMap, CountDownLatch, DeadLocks and more in further posts.

Forem: Aswathy Nair

Java Concurrency: ExecutorService, RejectionPolicies & ThreadPools — Part 2

ExecutorService

ThreadPoolExecutor — what is actually running under the hood

How task submission works internally

Rejection policies

CallerRunsPolicy

Custom rejection handler

Pitfall #1: DiscardPolicy

shutdown() vs shutdownNow()

Pitfall #2: shutdownNow() does not guarantee threads stop

ThreadPool types

Pitfall #3: newCachedThreadPool under load

Scheduled tasks — scheduleAtFixedRate vs scheduleWithFixedDelay

What if the task takes longer than the interval?

Stopping a scheduled task after N executions

Thread states

BLOCKED vs WAITING

ThreadLocal

How it works internally

Pitfall #4: The ThreadLocal memory leak

What's next?

Java Concurrency: From Threads to Thread Safety — Part 1

Processes vs. Threads

What threads share vs What they own

Creating a thread: The Two Ways

Way 1: Extend the Thread Class

Way 2: Implement Runnable

Pitfall #1

The Static Variable and join()

Pitfall #2: The Race Condition

Callable & FutureTask

ExecutorService & Future

Pitfall #3

Shared State

Pitfall #4

Fixing the Race Condition

Lock-Free Concurrency (Atomics)

What's Next?

The Static Variable and `join()`