Concurrency & Threads

// Preferred: implementing Runnable
Runnable task = () -> System.out.println("Running in: " + Thread.currentThread().getName());
Thread thread = new Thread(task);
thread.start();

// Less preferred: extending Thread directly
class MyThread extends Thread {
    @Override
    public void run() { System.out.println("Running"); }
}

Common follow-ups: What happens if you call run() directly instead of start() -- does it actually run on a new thread?;Why can a class only extend Thread OR implement Runnable, not benefit from both approaches simultaneously?

public class Counter {
    private int count = 0;

    public synchronized void increment() {  // locks 'this' for the duration of the method
        count++;  // without synchronization, this read-modify-write is NOT atomic and races under concurrency
    }

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

Common follow-ups: What's the difference between synchronizing on 'this' versus a dedicated private lock object?;Why is the count++ operation not atomic even though it looks like a single statement?

private final ReentrantLock lock = new ReentrantLock();

public boolean tryUpdate() {
    if (lock.tryLock()) {  // non-blocking attempt, unlike synchronized which would wait indefinitely
        try {
            // critical section
            return true;
        } finally {
            lock.unlock();  // MUST be in finally -- unlike synchronized, unlock isn't automatic
        }
    }
    return false;  // couldn't acquire the lock, caller can decide to retry, skip, or fail fast
}

Common follow-ups: Why must lock.unlock() always be called in a finally block, unlike synchronized's automatic release?;When would you choose synchronized's simplicity over ReentrantLock's additional flexibility?

ExecutorService executor = Executors.newFixedThreadPool(4);

Future<Integer> future = executor.submit(() -> {
    // some computation
    return 42;
});

try {
    Integer result = future.get(5, TimeUnit.SECONDS);  // blocks with a timeout
} catch (TimeoutException e) {
    future.cancel(true);
}

executor.shutdown();  // initiates graceful shutdown, letting in-flight tasks complete

Common follow-ups: What's the difference between Executors.newFixedThreadPool() and newCachedThreadPool(), and when is each appropriate?;Why do many teams recommend against using the Executors factory methods directly in production, preferring explicit ThreadPoolExecutor configuration?

CompletableFuture<User> userFuture = fetchUserAsync(userId);

// thenApply: simple synchronous transformation of the result
CompletableFuture<String> nameFuture = userFuture.thenApply(User::getName);

// thenCompose: chaining another ASYNC operation, avoiding nested CompletableFuture<CompletableFuture<T>>
CompletableFuture<List<Order>> ordersFuture = userFuture.thenCompose(user -> fetchOrdersAsync(user.getId()));

// thenCombine: merge two independent async operations once both complete
CompletableFuture<Report> reportFuture = userFuture.thenCombine(fetchInventoryAsync(), (user, inventory) -> buildReport(user, inventory));

Common follow-ups: What happens to exceptions thrown partway through a CompletableFuture chain, and how does exceptionally()/handle() address this?;What thread does each stage of a CompletableFuture chain actually execute on by default?

// DEADLOCK RISK: inconsistent lock ordering across two methods
public void transferAtoB() {
    synchronized (lockA) {
        synchronized (lockB) { /* transfer */ }
    }
}
public void transferBtoA() {
    synchronized (lockB) {  // acquires in OPPOSITE order -- deadlock risk if called concurrently!
        synchronized (lockA) { /* transfer */ }
    }
}

// FIX: always acquire in the same consistent global order (e.g., by object identity hash)
// regardless of the logical "direction" of the operation

Common follow-ups: What other deadlock prevention strategies exist besides consistent lock ordering (like tryLock with timeout)?;How would you use a thread dump to diagnose an actual deadlock occurring in a running production application?

public class FlagExample {
    private volatile boolean running = true;  // volatile ensures visibility across threads

    public void stop() {
        running = false;  // write is guaranteed visible to other threads reading 'running'
    }

    public void doWork() {
        while (running) {  // without volatile, this loop might NEVER see the update, looping forever
            // work
        }
    }
}

Common follow-ups: Why doesn't volatile make a compound operation like count++ atomic, and what's needed instead (AtomicInteger, synchronized)?;What specific compiler/CPU reordering optimizations does volatile prevent that could otherwise break multithreaded correctness?

private final AtomicInteger counter = new AtomicInteger(0);

public void increment() {
    counter.incrementAndGet();  // atomic, thread-safe, no explicit lock needed
}

public int compareAndUpdate(int expected, int newValue) {
    return counter.compareAndSet(expected, newValue) ? newValue : counter.get();
}

Common follow-ups: How does compare-and-swap (CAS) work at the CPU instruction level to achieve atomicity without a traditional lock?;Under what contention conditions might a CAS-based atomic actually perform worse than a traditional lock?

// CountDownLatch: wait for N worker threads to finish initialization before starting
CountDownLatch latch = new CountDownLatch(3);
for (int i = 0; i < 3; i++) {
    new Thread(() -> { initialize(); latch.countDown(); }).start();
}
latch.await();  // blocks main thread until all 3 have counted down

// Semaphore: limit concurrent access to at most 5 threads at a time
Semaphore semaphore = new Semaphore(5);
semaphore.acquire();
try { callLimitedResource(); } finally { semaphore.release(); }

Common follow-ups: Why is CyclicBarrier reusable across multiple 'rounds' while CountDownLatch is strictly one-time-use?;How does a Semaphore differ conceptually from a simple mutex/lock in terms of the guarantees it provides?

// Non-fair (default) ReentrantLock -- higher throughput, but theoretically allows starvation
ReentrantLock lock = new ReentrantLock();  // fair = false by default

// Fair lock -- reduces (but doesn't eliminate) starvation risk, at the cost of some throughput
ReentrantLock fairLock = new ReentrantLock(true);

Common follow-ups: Why is Thread priority considered an unreliable mechanism across different JVM/OS combinations?;What's the throughput cost of enabling fairness on a ReentrantLock, and when is that trade-off worthwhile?