Java Thread Safety: synchronized, Locks, volatile and Atomic Variables (1Z0-831)

Code is thread-safe when it behaves correctly no matter how the scheduler interleaves the threads that call it, with no extra coordination by the callers. It breaks when two threads touch the same mutable state and at least one of them writes without a shared lock or other happens-before guarantee: that is a data race, and the classic symptom is a lost update.

class Counter {
    private int count;

    void increment() {
        count++;          // read, add 1, write: three steps
    }

    int get() {
        return count;
    }
}

count++ looks like one action but is a read-modify-write: read count, add 1, store the result. Two threads can both read 41 and both store 42, so one increment disappears. Run two threads that each call increment() a million times and the total is often below two million, and different on every run. The result of racy code is not determined by the program: it can be any value up to the maximum and can change from run to run.

A second shape of the same bug is check-then-act: if (x == null) x = create(); or if (!map.containsKey(k)) map.put(k, v);. Another thread can act between the check and the act. Writing count = count + 1 instead of count++ changes nothing — it is the same three steps.

There are three ways to make shared state safe:

• Don't share it — keep data confined to one thread (local variables are always thread-confined).
• Don't mutate it — immutable objects (records with immutable components, String, List.of) can be shared freely once safely published.
• Coordinate access — guard every read and write of the state with the same lock (synchronized or a Lock), or use a class that does the compound action atomically (AtomicInteger, the concurrent collections).

The rest of this lesson is the third option. Thread-safe collections and parallel streams are covered in the objective 8.3 lesson.

Every Java object has one intrinsic lock, called its monitor, and synchronized acquires exactly one monitor on entry and releases it on exit. Two pieces of synchronized code exclude each other only if they lock the same object; what matters is which monitor each form uses.

public class Main {
    private static final Object LOCK = new Object();
    private int instanceCount;
    private static int classCount;

    synchronized void a() {
        System.out.println("a: this=" + Thread.holdsLock(this)
            + " class=" + Thread.holdsLock(Main.class));
    }

    static synchronized void b() {
        System.out.println("b: class=" + Thread.holdsLock(Main.class)
            + " LOCK=" + Thread.holdsLock(LOCK));
    }

    void c() {
        synchronized (LOCK) {
            System.out.println("c: LOCK=" + Thread.holdsLock(LOCK)
                + " this=" + Thread.holdsLock(this));
        }
    }

    public static void main(String[] args) {
        var m = new Main();
        m.a();
        b();
        m.c();
    }
}

Output (run on JDK 25):

a: this=true class=false
b: class=true LOCK=false
c: LOCK=true this=false

Thread.holdsLock(obj) reports whether the current thread owns obj's monitor. Calls on two different instances of a class can run a synchronized instance method at the same time, and an instance method and a static method never block each other. That is why a synchronized instance method does not protect a static field when each thread uses its own instance — the field needs a static lock (static synchronized or synchronized (Main.class)).

Rules for the block form:

• The expression must be a reference type; a primitive does not compile, and null throws NullPointerException at run time.
• Lock a private final dedicated object. Locking a field that is reassigned (for example a boxed Integer that count++ replaces with a new object) means threads can lock different objects and race; javac only warns about synchronizing on a value-based class such as Integer.
• Locking a fresh object (synchronized (new Object())) or Thread.currentThread() gives each thread its own monitor and protects nothing.
• synchronized is a modifier for methods and a statement for blocks; it is not allowed on fields, constructors or classes. An overriding method can add or drop synchronized freely — it is not part of the signature.

The monitor is released however the block exits — normally, by return, or by an exception — so synchronized never leaks a lock. A thread that waits for a monitor is in state BLOCKED and cannot be interrupted out of that wait.

Reentrancy: re-entering a lock you already hold

Intrinsic locks are reentrant: a thread that already owns a monitor can enter any other code synchronized on the same monitor without blocking. The JVM keeps a hold count per monitor — it goes up on each entry and down on each exit, and the monitor is free only when it reaches zero.

public class Main {
    private final Object lock = new Object();

    void outer() {
        synchronized (lock) {
            middle();
        }
    }

    void middle() {
        synchronized (lock) {
            try {
                throw new IllegalStateException("boom");
            } catch (IllegalStateException e) {
                System.out.println("caught, held=" + Thread.holdsLock(lock));
            }
        }
    }

    public static void main(String[] args) {
        var m = new Main();
        m.outer();
        System.out.println("after, held=" + Thread.holdsLock(m.lock));
    }
}

Output (run on JDK 25):

caught, held=true
after, held=false

Reentrancy is what makes these ordinary patterns safe instead of self-deadlocking:

• a synchronized method that calls another synchronized method on this;
• a synchronized override that calls super.m(), which is synchronized on the same object;
• nested synchronized (lock) blocks on the same lock, directly or through method calls.

A thread that calls wait() on a monitor it holds several times releases all its holds while waiting, so another thread can enter; when it wakes it reacquires the monitor with its previous hold count restored. ReentrantLock is reentrant in the same way (see below), and so are both locks of a ReentrantReadWriteLock.

A volatile field guarantees that every read sees the most recent write by any thread, and that writes made before a volatile write are visible to a thread that later reads that volatile value. It does not make compound actions atomic: v++ on a volatile field still loses updates.

Without any synchronization, the Java Memory Model lets the JIT keep a plain field in a register or hoist its read out of a loop. A worker spinning on while (running) with a plain boolean may never see another thread set it to false. Marking the field volatile fixes that because the JMM defines a happens-before edge from each volatile write to every later read of the same field. The edges you need to know:

• An unlock of a monitor or Lock happens-before every later lock of the same monitor or Lock.
• A write to a volatile field happens-before every later read of that field.
• Thread.start() happens-before every action in the started thread.
• Every action in a thread happens-before another thread returns from join() on it.
• Program order inside one thread, and transitivity: if A happens-before B and B before C, then A before C.

Transitivity is what makes the safe publication idiom work: a thread writes plain fields, then writes volatile boolean ready = true; any thread that reads ready as true is guaranteed to see the plain writes made before it. A volatile read never blocks — it just reads the current value.

volatile is a field modifier only — not for local variables, methods or classes. It is the right tool for a flag one thread writes and others read; the moment a value depends on its old value, use an atomic class or a lock.

The classes in java.util.concurrent.atomic — AtomicInteger, AtomicLong, AtomicBoolean, AtomicReference and the array variants — update a single variable atomically without a lock, using hardware compare-and-set. Their reads and writes also have volatile visibility.

The method name tells you which value comes back: getAndX returns the value before the change, xAndGet returns the value after it.

import java.util.concurrent.atomic.AtomicInteger;
import java.util.concurrent.atomic.AtomicLong;

public class Main {
    public static void main(String[] args) {
        var n = new AtomicInteger(10);
        System.out.println(n.getAndAdd(5) + " " + n.get());
        System.out.println(n.addAndGet(5) + " " + n.get());
        System.out.println(n.decrementAndGet() + " "
            + n.getAndDecrement() + " " + n.get());
        System.out.println(n.compareAndSet(18, 0) + " "
            + n.compareAndSet(17, 0) + " " + n.get());
        var max = new AtomicLong(4);
        System.out.println(max.accumulateAndGet(9, Math::max) + " "
            + max.getAndUpdate(x -> x + 1) + " "
            + max.updateAndGet(x -> x * 2));
    }
}

Output (run on JDK 25):

10 15
20 20
19 19 18
true false 0
9 9 20

Trace these one call at a time, writing down the stored value and the returned value separately. The update and accumulate functions may be re-applied when another thread wins the race, so they must be side-effect-free. Replacing a racy count++ with count.incrementAndGet() makes the counter exact. For a counter that many threads hit constantly and that is read rarely, LongAdder (increment(), sum()) scales better than AtomicLong. Atomic classes cover one variable: keeping two variables consistent with each other still needs a lock.

java.util.concurrent.locks.Lock is an explicit lock: you call lock() to acquire and unlock() to release, and nothing releases it for you. ReentrantLock is its standard implementation, with the same mutual exclusion, reentrancy and memory effects as synchronized, plus non-blocking, timed and interruptible acquisition, fairness and several conditions per lock.

Because an exception does not release a Lock, the only correct shape is acquire, then try, then unlock() in finally:

lock.lock();
try {
    // guarded work, which may throw
} finally {
    lock.unlock();
}

if (lock.tryLock()) {          // only unlock what you acquired
    try {
        // guarded work
    } finally {
        lock.unlock();
    }
} else {
    // do something else
}

Variants that look similar fail on one path: unlock() as a plain statement after the work (or after an empty finally) is skipped when the work throws; unlock() only in a catch is skipped when the work succeeds. Call lock() before the try, so a failed acquisition never reaches an unlock().

Ownership is checked. unlock() by a thread that does not hold the lock — one that never called lock(), whose tryLock() returned false, or that is simply a different thread — throws IllegalMonitorStateException (an unchecked exception; it compiles fine). A thread that ends while holding a Lock does not release it: the lock stays held and other threads wait forever. Each lock() by the owner adds one to the hold count and each unlock() removes one; the lock is free only at zero.

import java.util.concurrent.TimeUnit;
import java.util.concurrent.locks.ReentrantLock;

public class Main {
    public static void main(String[] args) throws Exception {
        var lock = new ReentrantLock();
        lock.lock();
        lock.lock();
        System.out.println(lock.getHoldCount() + " "
            + lock.isHeldByCurrentThread() + " " + lock.isLocked());
        Thread other = new Thread(() -> {
            try {
                boolean got = lock.tryLock(20, TimeUnit.MILLISECONDS);
                System.out.println("other got: " + got);
                lock.unlock();
            } catch (InterruptedException e) {
                System.out.println("interrupted");
            } catch (IllegalMonitorStateException e) {
                System.out.println("other: IllegalMonitorStateException");
            }
        });
        other.start();
        other.join();
        lock.unlock();
        lock.unlock();
        System.out.println(lock.getHoldCount() + " " + lock.isLocked());
    }
}

Output (run on JDK 25):

2 true true
other got: false
other: IllegalMonitorStateException
0 false

Useful ReentrantLock queries: getHoldCount() (holds by the current thread, 0 if it is not the owner), isHeldByCurrentThread(), isLocked() (held by any thread), isFair() and hasQueuedThreads(). new ReentrantLock(true) creates a fair lock that grants access roughly in arrival order, which reduces starvation at a throughput cost; it does not prevent deadlock, and the untimed tryLock() barges in even on a fair lock if the lock happens to be free.

The four acquisition methods differ in whether they wait, for how long, and whether an interrupt can stop the wait. Only two of them declare the checked InterruptedException, so they must be inside a try/catch or a method that declares it — including inside a Runnable lambda, whose run() declares nothing (unlike Callable.call(), which declares throws Exception, so a Callable lambda may let it propagate).

There is exactly one timed overload, tryLock(long, TimeUnit): tryLock(100) and tryLock(Duration.ofMillis(100)) do not compile. A thread parked in lock() or lockInterruptibly() shows state WAITING (TIMED_WAITING in a timed tryLock), unlike the BLOCKED state of a thread waiting for a monitor. Interrupting a thread stuck in lockInterruptibly() makes it throw InterruptedException without acquiring the lock, so it must not call unlock() afterwards; the same interrupt sent to a thread in lock() only sets its interrupt flag. These choices are the tools for responsive code: fail fast with tryLock(), bound the wait with the timed form, or let a supervisor cancel the wait with lockInterruptibly().

ReentrantReadWriteLock holds a pair of locks: any number of threads can hold the read lock at the same time, but the write lock is exclusive — it is granted only when no thread holds either lock. Use it when reads vastly outnumber writes; you get each lock through readLock() and writeLock() and use them with the same try/finally idiom.

The same-thread rules are asymmetric:

• No upgrade. A thread holding the read lock cannot get the write lock: writeLock().tryLock() returns false, and a blocking writeLock().lock() waits forever for its own read lock to go away. Release the read lock first, then acquire the write lock, and re-check the state, since another writer may have run in between.
• Downgrade is allowed. A thread holding the write lock may acquire the read lock, then release the write lock, keeping a consistent view while letting other readers in.

import java.util.concurrent.locks.ReentrantReadWriteLock;

public class Main {
    private final ReentrantReadWriteLock rw = new ReentrantReadWriteLock();
    private String value = "v1";

    String read() {
        rw.readLock().lock();
        try {
            return value;
        } finally {
            rw.readLock().unlock();
        }
    }

    String updateThenRead(String next) {
        rw.writeLock().lock();
        try {
            value = next;
            rw.readLock().lock();      // downgrade: take read first
        } finally {
            rw.writeLock().unlock();   // then release write
        }
        try {
            return value + " readers=" + rw.getReadLockCount();
        } finally {
            rw.readLock().unlock();
        }
    }

    public static void main(String[] args) {
        var m = new Main();
        System.out.println(m.read());
        System.out.println(m.updateThenRead("v2"));
        m.rw.readLock().lock();
        System.out.println("upgrade? " + m.rw.writeLock().tryLock());
        m.rw.readLock().unlock();
    }
}

Output (run on JDK 25):

v1
v2 readers=1
upgrade? false

Both locks are reentrant, and the write lock supports newCondition(). StampedLock offers a similar read/write split with optimistic reads, but it is not reentrant.

wait(), notify() and notifyAll() are Object methods that let a thread sleep until another thread changes some shared state; they can be called only by a thread that owns that object's monitor, otherwise they throw IllegalMonitorStateException at run time. The code still compiles — the compiler does not check lock ownership — but wait declares the checked InterruptedException, so the call must be caught or declared.

What happens step by step:

1. The waiter enters synchronized (lock), tests its condition and calls lock.wait(). That releases the monitor (all holds) and parks the thread in state WAITING.
2. Another thread enters synchronized (lock), changes the state, and calls notify() (wakes one waiting thread, chosen arbitrarily) or notifyAll() (wakes all of them).
3. The woken thread cannot continue until the notifier leaves its synchronized block; it then competes for the monitor, reacquires it and returns from wait().

Always wait in a while loop over the condition, never an if: a thread can wake spuriously, another woken thread may have consumed the state first, and a notification sent when nobody is waiting is simply lost — notify has no memory, so a waiter that checks the flag first never waits for a signal that already happened.

Condition is the same mechanism for a Lock: create it with lock.newCondition(), and call await(), signal() and signalAll() while holding that lock (a ReentrantLock condition throws IllegalMonitorStateException otherwise). One lock can have several conditions, such as notEmpty and notFull, so you wake only the threads that care.

import java.util.ArrayDeque;
import java.util.Deque;
import java.util.concurrent.locks.Condition;
import java.util.concurrent.locks.ReentrantLock;

public class Main {
    private final ReentrantLock lock = new ReentrantLock();
    private final Condition notEmpty = lock.newCondition();
    private final Deque<Integer> items = new ArrayDeque<>();

    void put(int x) {
        lock.lock();
        try {
            items.addLast(x);
            notEmpty.signal();
        } finally {
            lock.unlock();
        }
    }

    int take() throws InterruptedException {
        lock.lock();
        try {
            while (items.isEmpty()) {
                notEmpty.await();
            }
            return items.removeFirst();
        } finally {
            lock.unlock();
        }
    }

    public static void main(String[] args) throws Exception {
        var box = new Main();
        Thread consumer = new Thread(() -> {
            try {
                int sum = 0;
                for (int i = 0; i < 3; i++) {
                    sum += box.take();
                }
                System.out.println("sum " + sum);
            } catch (InterruptedException e) {
                System.out.println("interrupted");
            }
        });
        consumer.start();
        for (int i = 1; i <= 3; i++) {
            box.put(i * 10);
        }
        consumer.join();
    }
}

Output (run on JDK 25):

sum 60

Do not mix them up: calling wait() on a Condition object uses the condition's own monitor, not the lock, and throws IllegalMonitorStateException unless you synchronized on the condition itself.

The three synchronizers coordinate threads without guarding data: a CountDownLatch lets threads wait until a count reaches zero once, a CyclicBarrier makes a fixed group of threads wait for each other repeatedly, and a Semaphore limits how many threads use a resource at once.

CountDownLatch. countDown() on a latch already at zero does nothing — the count never goes negative and nothing is thrown. await() returns immediately at zero and otherwise blocks; it throws InterruptedException only when interrupted. await(time, unit) returns false on timeout (no exception) and true when the count reaches zero.

CyclicBarrier. Each await() blocks until parties threads have called it. The last thread to arrive runs the barrier action once (if any), then all are released and the barrier resets for the next round — so n rounds trip it n times. await() declares InterruptedException and BrokenBarrierException; the timed form adds TimeoutException. If a waiting thread times out or is interrupted, the barrier becomes broken: the other waiters, and every later await(), throw BrokenBarrierException at once until reset() is called.

Semaphore. acquire() takes a permit, blocking if none is left (throws InterruptedException); acquireUninterruptibly() waits without it. tryAcquire() and tryAcquire(n) return false at once if not enough permits are available and declare no checked exception, while the timed tryAcquire(time, unit) declares InterruptedException. Permits are just a count: any thread may release(), even one that never acquired, and releasing more than you acquired raises the count above its initial value. That is the key difference from a lock — Semaphore(1) works as a mutex but with no ownership check and no reentrancy.

import java.util.concurrent.CountDownLatch;
import java.util.concurrent.CyclicBarrier;
import java.util.concurrent.Semaphore;

public class Main {
    public static void main(String[] args) throws Exception {
        var ready = new CountDownLatch(3);
        for (int i = 0; i < 3; i++) {
            new Thread(ready::countDown).start();
        }
        ready.await();
        System.out.println("latch " + ready.getCount());

        var barrier = new CyclicBarrier(2,
            () -> System.out.println("trip"));
        Thread t = new Thread(() -> {
            try {
                barrier.await();
                barrier.await();
            } catch (Exception e) {
                System.out.println("broken");
            }
        });
        t.start();
        barrier.await();
        barrier.await();
        t.join();
        System.out.println("waiting " + barrier.getNumberWaiting());

        var pool = new Semaphore(2);
        System.out.println(pool.tryAcquire(2) + " "
            + pool.tryAcquire() + " " + pool.availablePermits());
        pool.release(3);
        System.out.println(pool.availablePermits());
    }
}

Output (run on JDK 25):

latch 0
trip
trip
waiting 0
true false 0
3

Liveness failures are bugs where threads stop making progress even though nothing is corrupted: in a deadlock threads are blocked forever waiting for each other, in a livelock they keep running but keep undoing each other's attempts, and in starvation one thread rarely or never gets a resource that others keep winning.

A deadlock needs a cycle of threads each holding a lock and waiting for the next. Breaking the cycle is the fix; changing timing is not. Anything that only changes timing or scheduling — shorter sleeps, priorities, fairness — makes the hang rarer at best, because the threads still wait for each other. Two designs that do work:

• Consistent lock ordering — every thread acquires the locks in the same order (for example by an id), so a cycle cannot form.
• Non-blocking acquisition — take the second lock with tryLock() or a timed tryLock; on failure release what you hold and try again later, after a random pause so that two threads don't collide again (that collision is livelock).

import java.util.concurrent.locks.Lock;
import java.util.concurrent.locks.ReentrantLock;

public class Main {
    record Account(int id, Lock lock) {}

    static int moves;

    static void transfer(Account from, Account to) {
        Account first = from.id() < to.id() ? from : to;
        Account second = first == from ? to : from;
        first.lock().lock();
        try {
            second.lock().lock();
            try {
                moves++;
            } finally {
                second.lock().unlock();
            }
        } finally {
            first.lock().unlock();
        }
    }

    public static void main(String[] args) throws Exception {
        var a = new Account(1, new ReentrantLock());
        var b = new Account(2, new ReentrantLock());
        Thread t1 = new Thread(() -> {
            for (int i = 0; i < 100_000; i++) transfer(a, b);
        });
        Thread t2 = new Thread(() -> {
            for (int i = 0; i < 100_000; i++) transfer(b, a);
        });
        t1.start();
        t2.start();
        t1.join();
        t2.join();
        System.out.println("moves " + moves);
    }
}

Output (run on JDK 25):

moves 200000

Both threads move money between the same two accounts in opposite directions, but because each always locks the lower id first, they cannot deadlock and every one of the 200,000 guarded updates is kept. Keep critical sections short and avoid calling unknown code (callbacks, listeners) while holding a lock — both reduce the chance of contention, starvation and accidental lock cycles.