In this chapter, you tackle concurrency issues that arise during a Flash Sale scenario, focusing on diagnosing and resolving Race Conditions. You'll learn to use the `volatile` keyword for thread visibility, secure critical sections with `synchronized` and `ReentrantLock`, and avoid deadlocks. Additionally, you'll explore `CompletableFuture` for efficient asynchronous execution and leverage Java 21 Virtual Threads to handle massive user connections effectively.

The Flash Sale Disaster: Race Conditions

EASY

Imagine a huge online store running a Flash Sale. There's only one PlayStation 5 left. At precisely the same moment, User A and User B both click 'Buy'.

Behind the scenes, two web threads execute the `purchase()` method simultaneously. Both threads check `if (inventory > 0)`. Since neither has updated the inventory yet, both see `inventory = 1`. They both proceed, charge their respective credit cards, and decrement the inventory. The result? The inventory drops to `-1`.

This scenario is a classic example of a **Race Condition**, specifically a 'Check-Then-Act' problem. It happens when multiple threads read, act on, and modify shared data at the same time, leading to inconsistent results.

In this case, the shared state is the inventory count. When threads access shared data without proper synchronization, it can lead to unexpected outcomes like selling more products than available. The fix is to make the inventory reservation atomic while keeping remote work, such as payment calls, outside the critical section whenever possible.

Understanding race conditions is crucial for writing robust concurrent programs. They often arise in multithreaded environments where the execution order of threads affects the program's correctness.

Race Conditions occur when the outcome of a program depends on the non-deterministic timing of threads.
'Check-Then-Act' issues arise when a thread checks a condition (e.g., inventory > 0) but the state changes before the action is completed.
Shared state, like variables accessed by multiple threads, is a common source of concurrency issues.
Operations like `count++` are not atomic; they involve reading, modifying, and writing, which can be interrupted.
Proper synchronization is key to preventing race conditions and ensuring data consistency.
Keep the critical section narrow; do not hold locks during slow I/O like payment or network calls.


public Receipt buy() {
    synchronized (this) {
        if (inventory <= 0) {
            throw new OutOfStockException();
        }
        inventory--;
    }

    // Keep remote work outside the inventory lock.
    chargeCard();
    return new Receipt();
}

Locks and the 'synchronized' Keyword

EASY

Imagine you're running a flash sale, and hundreds of users are trying to buy the last few items. To prevent chaos, we need to control access to the code that mutates shared inventory. Java's `synchronized` keyword is one of the simplest tools for that job.

When you declare a method as `synchronized`, you're telling Java to lock the door to that method. Only one thread can enter at a time, while others wait their turn. This lock is tied to the object itself, known as the 'Intrinsic Lock' or 'Monitor'.

This approach effectively prevents race conditions for the in-memory critical section. However, you still need judgment about lock scope. Slow calls such as network requests, disk I/O, or payment processing should usually happen outside the synchronized region so the lock protects shared state without becoming a throughput bottleneck.

For example, if 1,000 users are trying to buy different items, they all line up for the same lock, creating a bottleneck. While `synchronized` is simple and effective for small-scale concurrency, it's not always the best choice for high-traffic scenarios.

The `synchronized` keyword ensures only one thread accesses a critical section at a time.
It makes operations atomic, preventing race conditions by locking the object's monitor.
Every Java object has an intrinsic lock used by `synchronized` to manage thread access.
Excessive synchronization can degrade performance by serializing concurrent requests.
Consider alternatives like `ReentrantLock` for more control in high-concurrency situations.


// Synchronize only the shared-state mutation.
public void buy() {
    synchronized (this) {
        if (inventory <= 0) {
            throw new OutOfStockException();
        }
        inventory--;
    }

    chargeCard();
}

Visibility and the 'volatile' Keyword

EASY

Imagine it's 5:00 PM, and the Flash Sale is supposed to end. The admin hits a button to set `isSaleActive` to `false`. Yet, for the next few minutes, customers are still getting discounts. What's going on?

In modern CPUs, each core has its own fast L1/L2 cache. Threads running on these cores might load the `isSaleActive` variable into their local cache to speed things up. When the admin changes the variable in main memory, these threads might not see the update immediately.

This is where the `volatile` keyword comes into play. By marking a variable as `volatile`, you instruct the Java Memory Model (JMM) to ensure that all threads read and write this variable directly from main memory, not from their local caches.

Using `volatile` guarantees that changes to the variable are visible to all threads immediately. However, remember that `volatile` does not handle atomicity. It won't prevent race conditions or provide locking.

In a Flash Sale scenario, marking `isSaleActive` as `volatile` ensures that when the admin ends the sale, all checkout threads see this change right away.

Threads can cache shared variables locally to boost performance.
Local caching can cause 'Visibility' issues where updates are not seen by other threads.
The `volatile` keyword ensures that a variable is always read from and written to main memory.
`volatile` solves Visibility problems but does not ensure Atomicity.
Use `volatile` for flags or status indicators that are read by multiple threads.


// Using 'volatile' ensures all threads see the latest value of this flag.
private volatile boolean isSaleActive = true;

public void endSale() {
    isSaleActive = false; // Change is immediately visible to all threads
}

Modern Locks: ReentrantLock

MID

In high-concurrency scenarios like flash sales, managing access to shared resources is crucial. Traditional synchronization with the `synchronized` keyword can be too rigid, leading to potential problems like deadlocks. A deadlock occurs when two threads each hold a lock that the other needs, causing both to wait indefinitely. This can bring your application to a standstill, requiring a server restart.

To address these limitations, Java offers `ReentrantLock`, a more flexible alternative. Unlike `synchronized`, `ReentrantLock` provides a mechanism to attempt locking with a timeout. This means you can try to acquire a lock and, if unsuccessful within a specified time, handle the situation gracefully rather than waiting forever.

Using `ReentrantLock`, you can implement a timeout strategy. For example, if a lock isn't acquired within three seconds, you can notify the user that the server is busy and suggest trying again later. This approach enhances the reliability of your application, especially under heavy load.

When using `ReentrantLock`, it's crucial to release the lock in a `finally` block. This ensures that the lock is always released, even if an exception occurs during the execution of the protected code. Failing to do so can lead to resource leaks and degraded application performance.

Incorporating `ReentrantLock` into your concurrency toolkit can significantly improve your application's ability to handle concurrent operations safely and efficiently.

Deadlocks occur when two threads are stuck waiting for each other's locks.
`synchronized` lacks a timeout, potentially causing indefinite waits.
`ReentrantLock` provides a `.tryLock(time)` method to avoid deadlocks.
Always release a `ReentrantLock` in a `finally` block to prevent resource leaks.
Using timeouts with locks helps maintain application responsiveness under load.


Lock lock = new ReentrantLock();

if (lock.tryLock(3, TimeUnit.SECONDS)) {
    try {
        processPayment();
    } finally {
        lock.unlock(); // CRITICAL: Always release in a finally block
    }
} else {
    throw new TimeoutException("Server too busy, try again.");
}

Thread Pools: Mastering ExecutorService

MID

Imagine you're handling a flash sale, and thousands of users are registering simultaneously. You need to send each new user a Welcome Email without delaying the HTTP response. A naive solution might be to create a new thread for each email task using `new Thread(emailTask).start()`. But this approach is risky.

Creating a new OS thread for each task can quickly exhaust system resources, especially if 10,000 users register at once. Each thread consumes significant memory, potentially leading to an `OutOfMemoryError` and crashing your server.

Instead, use a Thread Pool managed by Java's `ExecutorService`. A Thread Pool maintains a fixed number of threads, like 50, and reuses them for multiple tasks. When all threads are busy, additional tasks are queued until a thread becomes available.

This approach not only conserves resources but also ensures your server remains stable during traffic spikes. By throttling the workload, the server can handle the flash sale efficiently without crashing.

The `ExecutorService` interface provides methods for managing the lifecycle of the thread pool, including task submission and graceful shutdown. This is crucial for maintaining application performance and reliability.

Creating a new thread for each task (`new Thread()`) is inefficient and risky.
Thread Pools reuse a fixed number of threads, saving system resources.
The `ExecutorService` handles task queueing, execution, and shutdown.
Using Thread Pools prevents server crashes during high traffic.
ExecutorService provides a structured way to manage concurrency.


// Creates a pool of exactly 50 reusable threads.
ExecutorService emailPool = Executors.newFixedThreadPool(50);

// Submit the task to the pool. It executes when a thread is available.
emailPool.submit(() -> sendWelcomeEmail(user));

Concurrent Collections: Mastering ConcurrentHashMap

MID

Imagine you're running an online store during a flash sale. You need to track user sessions efficiently without causing your system to crash. Using a standard `HashMap` in a multithreaded environment can lead to data corruption. This happens because `HashMap` is not thread-safe, and concurrent writes can mess up its internal structure, leading to unpredictable behavior.

One might consider using `Collections.synchronizedMap()` to solve this. However, this approach places a single lock on the entire map, meaning only one thread can access it at a time. This severely limits concurrency, as even a simple read operation would have to wait for other operations to complete.

Enter `ConcurrentHashMap`, a more refined solution. It allows multiple threads to read and write simultaneously by using a technique called lock striping. This means only the specific segment of the map being accessed is locked, not the whole map. Thus, `ConcurrentHashMap` provides a balance between safety and performance.

In practice, `ConcurrentHashMap` is ideal for scenarios where high throughput and low latency are required, such as maintaining active user sessions during high traffic events. It ensures that your application remains responsive and efficient, even under heavy load.

Standard collections like `HashMap` are not suitable for concurrent use and can lead to data corruption.
Using `Collections.synchronizedMap()` locks the entire map, creating a single-threaded bottleneck.
`ConcurrentHashMap` allows concurrent access by locking only the necessary segments.
This approach offers thread safety and high performance, crucial for high-traffic applications.
Ideal for scenarios requiring both high throughput and low latency.


// Safely handle thousands of concurrent sessions.
Map<String, UserSession> sessions = new ConcurrentHashMap<>();

sessions.put("session_994", new UserSession());

Asynchronous Workflows with CompletableFuture

ADVANCED

Imagine you're tasked with rendering a complex dashboard. This dashboard requires fetching a User Profile, the User's recent Orders, and Recommended Products from the database. If each operation takes about a second and you execute them one after another, your user waits a frustrating 3 seconds.

Enter **`CompletableFuture`**. This Java class lets you execute these tasks concurrently, reducing the total wait time to just 1 second. By running tasks in parallel, you effectively utilize background threads, optimizing your application's responsiveness.

`CompletableFuture` isn't just about parallel execution; it's about creating a functional workflow. You can chain operations using methods like `.thenApply()` and `.thenCombine()`, making your code cleaner and more maintainable. For instance, you can fetch a profile, transform it, and then combine it with other data seamlessly.

Error handling is another strength of `CompletableFuture`. If any part of your workflow fails, you can define specific fallback strategies. This ensures your application remains robust, even when things don't go as planned.

Mastering `CompletableFuture` is crucial for building efficient, non-blocking applications, especially when dealing with aggregator API endpoints. It's a skill that can set you apart in technical interviews and real-world projects.

Sequential execution can lead to unnecessary delays, especially with I/O operations.
`CompletableFuture` enables parallel task execution, reducing total processing time.
It offers a fluent API for chaining asynchronous operations, enhancing code readability.
Error handling is built-in, allowing for predefined fallback strategies.
Ideal for optimizing performance in aggregator API endpoints.


CompletableFuture<Profile> profileFuture = CompletableFuture.supplyAsync(() -> fetchProfile());
CompletableFuture<Orders> ordersFuture = CompletableFuture.supplyAsync(() -> fetchOrders());

// Combine results from both futures once they complete
CompletableFuture<Dashboard> dashboardFuture = profileFuture.thenCombine(ordersFuture, (profile, orders) -> 
    new Dashboard(profile, orders)
);

Atomic Variables and Non-Blocking Algorithms

ADVANCED

In a high-stakes scenario like a Flash Sale, every millisecond counts. Imagine needing to update a counter that tracks how many items have been sold. Using a simple `int count` with `synchronized` locks would force each checkout thread to wait its turn, severely slowing down your transaction throughput.

Enter **`AtomicInteger`**. This class, part of Java's `java.util.concurrent.atomic` package, allows you to perform operations without locking the threads. It leverages a technique called 'Compare-And-Swap' (CAS) at the hardware level, which is both fast and efficient.

Here's how it works: a thread checks the value in memory, say 5, and attempts to change it to 6. If another thread has already updated it to 6, the CAS operation fails, and the thread retries. This all happens without any thread being locked, which is crucial for maintaining speed in high-load environments.

Atomic variables are particularly useful for simple counters and flags where performance is critical. They provide a non-blocking way to handle concurrency, which is essential for modern applications that demand high throughput.

Understanding when to use atomic variables versus locks is important. Locks are 'pessimistic', assuming conflicts will occur, while atomic operations are 'optimistic', assuming they won’t and handling them swiftly if they do.

Locks like `synchronized` are 'Pessimistic', assuming conflicts will occur and freezing other threads.
Atomic classes like `AtomicInteger` are 'Optimistic' and operate without locking, improving performance.
They use Compare-And-Swap (CAS) operations directly at the CPU level, ensuring atomicity.
Atomic variables are ideal for shared counters and basic state flags under high load.
Choosing between locks and atomic operations depends on the specific use case and performance needs.


private final AtomicInteger itemsSold = new AtomicInteger(0);

public void recordSale() {
    // Increment the counter atomically, ensuring thread safety without locks.
    itemsSold.incrementAndGet(); 
}

Virtual Threads: The Java 21 Revolution

ADVANCED

Imagine you're running a flash sale. During checkout, your application needs to call an external API, like Stripe, to process payments. But there's a hitch: the API is sluggish, taking 5 seconds to respond. With traditional thread pools, this can be a nightmare. If your pool is capped at 500 threads, and all are tied up waiting for Stripe, your 501st customer is left out in the cold. That's where Java 21's Virtual Threads come in.

Virtual Threads, introduced with Project Loom, are a game-changer. They're so lightweight that you can create millions without breaking a sweat. Unlike traditional OS threads, Virtual Threads are managed by the JVM, not the operating system. This means they don't hog memory, allowing you to scale your application effortlessly.

When a Virtual Thread is blocked on I/O, such as waiting for a slow API response, the JVM detaches the underlying OS thread, freeing it up to handle other tasks. This dynamic management means you can write straightforward, blocking code without worrying about thread exhaustion.

For developers, this simplifies concurrency. You no longer need to juggle complex asynchronous patterns or worry about thread pool limits. Virtual Threads let you focus on writing clean, maintainable code that scales with demand.

Traditional OS threads are heavy, limiting scalability to a few thousand.
Blocking I/O calls waste threads, causing bottlenecks in high-demand scenarios.
Virtual Threads in Java 21 are lightweight and managed by the JVM, not the OS.
They allow millions of concurrent threads, improving scalability and performance.
When blocked, Virtual Threads release their OS thread for other tasks, optimizing resource use.


// Effortlessly manage 100,000 concurrent virtual threads without overwhelming the system
try (var executor = Executors.newVirtualThreadPerTaskExecutor()) {
    for (int i = 0; i < 100000; i++) {
        executor.submit(() -> callSlowStripeApi());
    }
}

Chapter takeaway

Understanding concurrency is crucial for building reliable Java applications. Mastering thread safety, concurrent collections, and modern asynchronous techniques will significantly enhance your ability to develop scalable and robust backend systems.