Multithreading and Concurrency

The Foundation: Thread Lifecycle and Execution

At the core of Java concurrency is the Thread class, which serves as the fundamental unit of execution. When you instantiate a Thread and call start(), the Java Virtual Machine triggers the underlying operating system to allocate resources and execute the run() method. It is critical to understand that starting a thread does not guarantee immediate execution; the thread scheduler determines when a thread runs based on priority and availability. Because threads share the same memory heap, they are lightweight compared to processes, but this shared access introduces the primary challenge of concurrency: state visibility and race conditions. By implementing the Runnable interface or extending Thread, you define the task, but the scheduler governs the life cycle. Mastery of the thread state—New, Runnable, Blocked, Waiting, Timed Waiting, and Terminated—is essential because improper management can lead to thread starvation, where a thread never gains CPU time, or resource leaks that consume application memory over long periods.

public class WorkerTask implements Runnable {
    @Override
    public void run() {
        // The task logic runs in a separate execution stack
        System.out.println("Thread " + Thread.currentThread().getName() + " is executing.");
    }

    public static void main(String[] args) {
        Thread thread = new Thread(new WorkerTask());
        thread.start(); // Initiates lifecycle transitions
    }
}

Synchronized Blocks and Intrinsic Locks

When multiple threads modify shared state, they can interfere with one another, leading to inconsistent data. Java provides the 'synchronized' keyword to enforce mutual exclusion using intrinsic locks (also known as monitor locks). When a thread enters a synchronized block or method, it must acquire the lock associated with the object instance. If another thread already holds that lock, the requester is moved to a blocked state until the owner releases it. The reason this works is that the JVM guarantees that only one thread can hold an object's monitor at any given time, providing both atomicity and memory visibility. Without synchronization, changes made by one thread might remain in the processor's local cache and not be visible to other threads reading from main memory. Use synchronized blocks sparingly, as excessive locking creates contention where threads spend more time waiting for locks than performing actual useful work.

public class Counter {
    private int count = 0;

    // Method-level synchronization locks the 'this' instance
    public synchronized void increment() {
        count++; // Atomicity ensured by monitor lock
    }

    public synchronized int getCount() {
        return count;
    }
}

Volatile and Atomic Variables

While 'synchronized' provides heavy-duty locking, simpler concurrency needs can often be solved with 'volatile' or atomic classes. The 'volatile' keyword ensures that a variable is always read from and written to main memory, preventing threads from using potentially stale cached copies. It essentially creates a happens-before relationship, where any write to a volatile field is guaranteed to be visible to subsequent reads. However, volatile does not provide atomicity for compound operations like incrementing (i+1); for that, the 'java.util.concurrent.atomic' package provides classes like AtomicInteger. These classes utilize low-level Compare-And-Swap (CAS) instructions provided by the hardware. CAS is a non-blocking algorithm that attempts to update a value only if it matches the expected current value. If it fails, it retries in a tight loop. This is generally more performant than locking because it avoids the overhead of context switching and thread suspension required by synchronized blocks.

import java.util.concurrent.atomic.AtomicInteger;

public class SafeCounter {
    // AtomicInteger ensures thread-safe operations without explicit locks
    private final AtomicInteger count = new AtomicInteger(0);

    public void increment() {
        // Uses non-blocking CAS instructions internally
        count.incrementAndGet();
    }

    public int getValue() {
        return count.get();
    }
}

High-Level Concurrency with Executors

Manually creating and managing threads is error-prone and resource-intensive because thread creation is expensive. The Executor framework abstracts this by providing a thread pool that manages a set of worker threads. When you submit a task to an ExecutorService, it is placed in an internal queue and assigned to an available worker thread. This mechanism separates task submission from execution policy. For example, a FixedThreadPool keeps a specific number of threads running, recycling them for multiple tasks, which prevents the system from crashing under the weight of excessive thread creation. Using executors is critical for production systems because they provide better control over thread lifecycle management, task scheduling, and error handling. By using these abstractions, you shift the focus from the 'how' of threading to the 'what' of the business logic, reducing the surface area for common concurrency bugs like thread exhaustion and resource leaks.

import java.util.concurrent.ExecutorService;
import java.util.concurrent.Executors;

public class TaskRunner {
    public static void main(String[] args) {
        // Manage a pool of 3 threads to handle multiple tasks
        ExecutorService executor = Executors.newFixedThreadPool(3);
        executor.submit(() -> System.out.println("Executing task"));
        executor.shutdown(); // Gracefully stops the executor
    }
}

Locks and Conditions for Advanced Synchronization

For scenarios requiring more granular control than intrinsic locks, the 'java.util.concurrent.locks' package provides the Lock interface. Unlike synchronized blocks, ReentrantLock allows you to attempt to acquire a lock without waiting indefinitely, supports fairness policies, and provides 'Condition' objects for complex signaling. A Condition allows a thread to suspend execution (await) until another thread signals it, which is much more efficient than spinning in a loop checking a flag. The 'tryLock()' method is particularly useful for avoiding deadlock because it allows a thread to give up if it cannot acquire the necessary resources within a specific timeframe. Understanding the distinction between these explicit locks and intrinsic locks is important: intrinsic locks are simpler and automatically released by the JVM, while explicit locks require a try-finally block to ensure they are always unlocked, even when exceptions occur, preventing permanent deadlocks.

import java.util.concurrent.locks.ReentrantLock;

public class ResourceGuard {
    private final ReentrantLock lock = new ReentrantLock();

    public void performAction() {
        lock.lock(); // Explicit locking
        try {
            // Safe access to shared resources
        } finally {
            lock.unlock(); // Always unlock in finally to avoid leaks
        }
    }
}

Interview questions

All java interview questions →

Check yourself

Take the full java quiz →