Synchronisation Mechanisms

What is Synchronisation?

Synchronisation is the set of mechanisms that control how threads access shared state and coordinate with each other. Without it, concurrent reads and writes produce undefined behaviour: lost updates, stale reads, and corrupted data structures.

Java's concurrency toolkit provides tools at two levels: mutual exclusion (only one thread at a time can access a resource — locks, synchronized, atomics) and thread coordination (threads signal each other about work completion, resource availability, or phase boundaries — latches, barriers, semaphores). Knowing which tool fits which problem is what separates a concurrent programmer from someone who sprinkles synchronized everywhere and hopes for the best.

/*
 *  Synchronisation tool selection guide:
 *
 *  Problem                              Tool
 *  ───────────────────────────────────  ─────────────────────────────
 *  Protect shared mutable state         synchronized / ReentrantLock
 *  Read-heavy, write-rare state         ReadWriteLock / StampedLock
 *  Single variable, simple ops          AtomicInteger / AtomicReference
 *  One-time gate (N threads wait)       CountDownLatch
 *  Reusable phase barrier               CyclicBarrier
 *  Limit concurrent access (N slots)   Semaphore
 *  Exchange data between two threads    Exchanger
 *  Visibility only, no atomicity        volatile
 */

ReentrantLock — When synchronized Is Not Enough

synchronized is simple and sufficient for most cases. Switch to ReentrantLock when you need: timed locking, interruptible waiting, fairness, multiple conditions, or lock inspection.

class BoundedBuffer<T> {
    private final Queue<T>    queue = new ArrayDeque<>();
    private final int           capacity;
    private final ReentrantLock lock  = new ReentrantLock();
    private final Condition      notFull  = lock.newCondition();
    private final Condition      notEmpty = lock.newCondition();

    public BoundedBuffer(int capacity) { this.capacity = capacity; }

    public void put(T item) throws InterruptedException {
        lock.lock();
        try {
            while (queue.size() == capacity) notFull.await();  // releases lock while waiting
            queue.add(item);
            notEmpty.signal();  // wake one consumer
        } finally {
            lock.unlock();  // ALWAYS in finally
        }
    }

    public T take() throws InterruptedException {
        lock.lock();
        try {
            while (queue.isEmpty()) notEmpty.await();
            T item = queue.poll();
            notFull.signal();  // wake one producer
            return item;
        } finally {
            lock.unlock();
        }
    }
}
// Two separate Conditions mean producers only wake producers-that-are-waiting,
// and consumers only wake consumers-that-are-waiting — no spurious wakeups of wrong side.

// tryLock with timeout — avoids blocking forever, prevents some deadlocks
if (lock.tryLock(100, TimeUnit.MILLISECONDS)) {
    try { doWork(); }
    finally { lock.unlock(); }
} else {
    metrics.increment("lock.timeout");
    throw new ServiceUnavailableException("Resource contended");
}

// lockInterruptibly — gives up if Thread.interrupt() is called
try {
    lock.lockInterruptibly();  // throws InterruptedException if interrupted while waiting
    try { doWork(); } finally { lock.unlock(); }
} catch (InterruptedException e) {
    Thread.currentThread().interrupt();
    // graceful shutdown: task was cancelled while waiting for lock
}

// Fair lock: threads acquire in FIFO order of waiting — prevents starvation
// Cost: lower throughput due to OS scheduling overhead
ReentrantLock fairLock = new ReentrantLock(true);  // fair=true

ReadWriteLock and StampedLock

When reads are far more frequent than writes, a single exclusive lock is wasteful — readers block each other unnecessarily. Read-write locks allow multiple concurrent readers OR one exclusive writer, never both at the same time.

ReentrantReadWriteLock

class ConfigCache {
    private final Map<String, String>    config = new HashMap<>();
    private final ReentrantReadWriteLock rwLock = new ReentrantReadWriteLock();
    private final Lock                   read   = rwLock.readLock();
    private final Lock                   write  = rwLock.writeLock();

    // Many threads can read simultaneously
    public String get(String key) {
        read.lock();
        try { return config.get(key); }
        finally { read.unlock(); }
    }

    // Only one writer at a time — blocks all readers during write
    public void reload(Map<String, String> newConfig) {
        write.lock();
        try {
            config.clear();
            config.putAll(newConfig);
        } finally { write.unlock(); }
    }
}

StampedLock — optimistic reads (Java 8+)

// StampedLock goes further: optimistic reads require NO lock acquisition.
// Assume no writer is active, read, then validate. If invalidated, fall back to read lock.
// Best throughput for read-heavy workloads.

class Point {
    private double x, y;
    private final StampedLock sl = new StampedLock();

    public double distanceFromOrigin() {
        // Optimistic read: no lock, just a stamp
        long stamp = sl.tryOptimisticRead();
        double cx = x, cy = y;

        // Validate: was a write happening while we read? If yes, retry with real lock.
        if (!sl.validate(stamp)) {
            stamp = sl.readLock();
            try { cx = x; cy = y; }
            finally { sl.unlockRead(stamp); }
        }
        return Math.sqrt(cx * cx + cy * cy);
    }

    public void move(double deltaX, double deltaY) {
        long stamp = sl.writeLock();
        try { x += deltaX; y += deltaY; }
        finally { sl.unlockWrite(stamp); }
    }
}

/*
 *  Performance hierarchy (read-heavy workloads, many threads):
 *  StampedLock (optimistic) > ReentrantReadWriteLock > ReentrantLock > synchronized
 *
 *  Caveat: StampedLock is NOT reentrant and has no Condition support.
 *  Don't use it if you need either of those.
 */

Thread Coordination Primitives

These tools don't protect data — they coordinate when threads can proceed. Choosing the right one makes intent explicit and avoids ad-hoc flag-and-notify patterns.

CountDownLatch — one-time gate

// N threads (or events) must complete before others proceed.
// Count goes down to zero; cannot be reset.

// Pattern 1: wait for N services to initialise before serving traffic
int serviceCount = 3;
CountDownLatch ready = new CountDownLatch(serviceCount);

List.of("db", "cache", "kafka").forEach(name ->
    executor.submit(() -> {
        initialise(name);
        ready.countDown();  // signal: this service is up
    })
);

ready.await();  // main thread blocks until all 3 services are ready
// ready.await(30, TimeUnit.SECONDS);  timeout variant
startServingTraffic();

// Pattern 2: starting gun — release N workers simultaneously
// (removes warm-up variation in benchmarks)
CountDownLatch startGun = new CountDownLatch(1);
CountDownLatch done     = new CountDownLatch(workerCount);

workers.forEach(w -> executor.submit(() -> {
    startGun.await();   // wait for the gun
    w.run();
    done.countDown();   // signal completion
}));

startGun.countDown();  // release all workers simultaneously
done.await();          // wait for all to finish

CyclicBarrier — reusable phase synchronisation

// All threads must reach the barrier before any can proceed.
// Unlike CountDownLatch, CyclicBarrier resets and can be reused.

// Classic use: parallel computation in phases
int workers = 4;
CyclicBarrier barrier = new CyclicBarrier(workers, () -> {
    // Barrier action: runs once when all threads arrive (on the last thread)
    mergePartialResults();
    log.info("Phase complete, next phase starting");
});

for (int i = 0; i < workers; i++) {
    final int partition = i;
    executor.submit(() -> {
        for (int phase = 0; phase < 3; phase++) {
            processPartition(partition, phase);
            barrier.await();  // wait for all others to finish this phase
            // barrier resets automatically — all 4 threads proceed to next phase
        }
    });
}

Semaphore — bounded concurrency

// Semaphore holds N permits. acquire() takes one; release() returns one.
// Use to limit concurrent access to a shared resource.

// Pattern: connection pool with max 10 concurrent connections
Semaphore permits = new Semaphore(10);

public Response callExternalApi(Request req) {
    if (!permits.tryAcquire(500, TimeUnit.MILLISECONDS)) {
        throw new TooManyRequestsException("API rate limit reached");
    }
    try {
        return httpClient.send(req);
    } finally {
        permits.release();  // always return the permit
    }
}

// Pattern: rate limiting — allow 5 requests per second
// (use with fixed delay reset to restore permits each second)

// Binary semaphore (1 permit) as an unfair mutex —
// unlike ReentrantLock, can be released from a DIFFERENT thread
Semaphore mutex = new Semaphore(1);

Exchanger — hand off between two threads

// Two threads meet at an exchange point and swap objects.
// Classic use: double-buffer producer-consumer (fill one buffer while other is consumed)

Exchanger<List<Event>> exchanger = new Exchanger<>();

// Producer thread: fills a buffer, then swaps with consumer
executor.submit(() -> {
    List<Event> buffer = new ArrayList<>();
    while (true) {
        buffer.add(readNextEvent());
        if (buffer.size() == 100) {
            buffer = exchanger.exchange(buffer);  // swap with consumer's empty buffer
            buffer.clear();
        }
    }
});

// Consumer thread: processes the full buffer, returns empty one
executor.submit(() -> {
    List<Event> buffer = new ArrayList<>();
    while (true) {
        buffer = exchanger.exchange(buffer);  // receive full buffer, give back empty
        buffer.forEach(this::processEvent);
    }
});

Java Memory Model — The Foundation

The Java Memory Model (JMM) defines when a write by one thread becomes visible to another. Without visibility guarantees, the JVM and CPU can reorder instructions, cache values in registers, or defer writes — all for performance. The JMM establishes happens-before rules that constrain this reordering.

/*
 *  HAPPENS-BEFORE (hb): if action A hb action B, then
 *  B is guaranteed to see all writes performed by A.
 *
 *  Key happens-before relationships:
 *
 *  1. Monitor lock:
 *     unlock(m)  hb  lock(m)
 *     Any write before unlock is visible to any thread that subsequently locks m.
 *
 *  2. volatile:
 *     write(v)  hb  read(v)
 *     A volatile write is visible to all subsequent reads of that variable.
 *
 *  3. Thread start:
 *     start(t)  hb  any action in t
 *     Everything done before t.start() is visible inside thread t.
 *
 *  4. Thread join:
 *     all actions in t  hb  t.join()
 *     Everything done in t is visible to whoever calls t.join().
 *
 *  5. Object construction:
 *     constructor end  hb  finalizer start
 *     final fields: safely published after constructor completes.
 *
 *  WITHOUT a hb relationship, you have no visibility guarantee,
 *  regardless of what the code looks like.
 */

Safe publication — sharing objects between threads

// ❌ Unsafe publication: another thread may see partial construction
class Holder {
    int value;
    Holder(int v) { this.value = v; }
}
Holder holder;  // shared field — no synchronisation

// Thread A:
holder = new Holder(42);  // Thread B may see: null, or Holder with value=0

// ✅ Safe publication mechanisms:

// 1. volatile field
volatile Holder holder = new Holder(42);

// 2. static initialiser (class loading is thread-safe)
static final Holder HOLDER = new Holder(42);

// 3. Immutable object: all fields final — safely published via any mechanism
record ImmutableHolder(int value) {}

// 4. ConcurrentHashMap, BlockingQueue, AtomicReference — their puts/offers
//    establish happens-before for whoever reads the value later

// 5. Synchronised access on the same monitor

The double-checked locking pitfall (and fix)

// ❌ Broken: the JMM allows object = new Singleton() to be reordered as:
//    1. allocate memory
//    2. assign reference to 'object'   ← other threads see non-null before step 3
//    3. initialise fields
class Singleton {
    private static Singleton instance;
    public static Singleton getInstance() {
        if (instance == null) {
            synchronized (Singleton.class) {
                if (instance == null)
                    instance = new Singleton();  // ← broken without volatile
            }
        }
        return instance;
    }
}

// ✅ Fix 1: volatile prevents the reordering
private static volatile Singleton instance;

// ✅ Fix 2: Initialization-on-demand holder — better, no volatile needed
class Singleton {
    private static class Holder {
        static final Singleton INSTANCE = new Singleton();
    }
    public static Singleton getInstance() { return Holder.INSTANCE; }
}
// Class loading of Holder is lazy and thread-safe — JVM guarantees it.

Common Pitfalls

// ❌ Different threads synchronise on DIFFERENT String instances
// String.intern() might help but never rely on it
synchronized ("shared") { ... }   // ❌ string literals ARE interned, but
synchronized (new String("s")) { ... } // ❌ different objects = no mutual exclusion

// ❌ Boolean wrapper: only two instances exist — accidental sharing
Boolean flag = true;
synchronized (flag) { ... }  // ❌ any code using Boolean.TRUE shares this lock

// ✅ Always use a dedicated private final Object as lock
private final Object lock = new Object();
synchronized (lock) { ... }  // ✅ private, can't be accidentally shared

// ❌ Calling unknown external code while holding a lock
// The external code may: acquire another lock (→ deadlock risk),
// spawn threads that try to acquire your lock, or run for a long time.
synchronized (this) {
    listener.onEvent(event);   // ❌ don't know what listener does
    database.save(entity);     // ❌ I/O inside a lock — terrible for performance
}

// ✅ Collect what you need under the lock, act outside it
List<EventListener> snapshot;
synchronized (this) {
    snapshot = List.copyOf(listeners);  // defensive copy, fast
}
snapshot.forEach(l -> l.onEvent(event));  // ✅ outside lock

// ❌ Spurious wakeups: threads can wake without notify()
// Always re-check the condition in a while loop
synchronized (this) {
    if (queue.isEmpty()) wait();  // ❌ may wake spuriously, queue still empty
    process(queue.poll());
}

// ✅ while loop re-checks the condition
synchronized (this) {
    while (queue.isEmpty()) wait();  // ✅ keep waiting until genuinely non-empty
    process(queue.poll());
}

Interview Questions