All 15 Concurrency & Threads questions
More in Concurrency & Threads
What are the two primary ways to create a thread in Java (extending Thread versus implementing Runnable), and which is generally preferred? What is the difference between calling Thread.start() and Thread.run() directly, and why is calling run() directly a common beginner mistake? What is the ExecutorService framework, and why is it generally preferred over manually creating and managing individual Thread objects? What causes a deadlock in multithreaded Java code, and what is the classic "lock ordering" strategy for preventing it? What are the atomic classes in java.util.concurrent.atomic (AtomicInteger, AtomicLong, AtomicReference), and how do they achieve thread-safe operations without traditional locking? What is thread starvation, and how can thread priority misuse or unfair lock scheduling contribute to it? What is the difference between wait()/notify()/notifyAll() (Object's intrinsic monitor methods) and the newer java.util.concurrent tools, and why are the older methods considered error-prone? What is a race condition, and how does it differ conceptually from a deadlock as two distinct categories of concurrency bugs? How does java.util.concurrent's ReentrantLock differ from the synchronized keyword, and what additional capabilities does it provide (tryLock, fairness, interruptible locking)? How do CompletableFuture's composition methods (thenApply, thenCompose, thenCombine) enable building asynchronous pipelines, and what's the difference between thenApply and thenCompose?
Advertisement
Java › Concurrency & Threads

What is the synchronized keyword, and how does it use Java's intrinsic (monitor) locks to prevent race conditions on shared mutable state?

Intermediate

Answer

synchronized (applied to a method, or as a block with an explicit object reference) ensures only one thread at a time can execute the protected code while holding that object's intrinsic monitor lock, with other threads attempting to enter blocking until the lock is released -- this prevents race conditions where multiple threads read-modify-write shared state concurrently in an interleaved, inconsistent way, though it comes with the cost of serializing access (potentially becoming a contention bottleneck) and the risk of deadlock if locks are acquired in inconsistent orders across different code paths.
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;
    }
}
Real-world example A shared counter incremented by multiple concurrent request-handling threads without synchronization exhibits a classic race condition ("lost updates", where the final count is lower than the actual number of increments due to interleaved read-modify-write operations), fixed by synchronizing the increment method to ensure each increment completes atomically.

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?

Diagnostics & Performance;Design Patterns in Java
All 15 Concurrency & Threads questions