Locks and Atomic Classes in Java

Why explicit locks exist

synchronized is simple but rigid: you cannot try to acquire, cannot give up after a timeout, cannot interrupt a waiting thread, and cannot separate readers from writers. The java.util.concurrent.locks package fills those gaps.

ReentrantLock

public class Inventory {

    private final ReentrantLock lock = new ReentrantLock();
    private final Map<String, Integer> stock = new HashMap<>();

    public void add(String item, int quantity) {
        lock.lock();
        try {
            stock.merge(item, quantity, Integer::sum);
        } finally {
            lock.unlock();          // must be in finally
        }
    }
}

The finally block is not optional. Unlike synchronized, an explicit lock is not released automatically when an exception unwinds the stack, and a lock left held stops every other thread permanently.

Trying, and giving up

if (lock.tryLock()) {                 // returns immediately
    try {
        doWork();
    } finally {
        lock.unlock();
    }
} else {
    handleBusy();
}

if (lock.tryLock(2, TimeUnit.SECONDS)) {   // waits, then gives up
    try {
        doWork();
    } finally {
        lock.unlock();
    }
}

lock.lockInterruptibly();     // can be cancelled by interrupting the thread

Fairness

ReentrantLock fair = new ReentrantLock(true);   // longest waiting thread wins

A fair lock prevents starvation but is noticeably slower, because it cannot hand the lock to a thread that happens to be running. Use it only when starvation is a demonstrated problem.

Conditions

public class BoundedBuffer<T> {

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

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

    public void put(T item) throws InterruptedException {
        lock.lock();
        try {
            while (items.size() == capacity) {
                notFull.await();
            }
            items.add(item);
            notEmpty.signalAll();
        } finally {
            lock.unlock();
        }
    }

    public T take() throws InterruptedException {
        lock.lock();
        try {
            while (items.isEmpty()) {
                notEmpty.await();
            }
            T item = items.poll();
            notFull.signalAll();
            return item;
        } finally {
            lock.unlock();
        }
    }
}

A Condition is the explicit lock equivalent of wait and notify, but one lock can have several. Producers wait on one and consumers on another, so a signal wakes only the threads that can actually make progress. An intrinsic lock has a single wait set and cannot do this.

ReadWriteLock

public class Settings {

    private final ReadWriteLock lock = new ReentrantReadWriteLock();
    private final Map<String, String> values = new HashMap<>();

    public String get(String key) {
        lock.readLock().lock();
        try {
            return values.get(key);       // many readers at once
        } finally {
            lock.readLock().unlock();
        }
    }

    public void set(String key, String value) {
        lock.writeLock().lock();
        try {
            values.put(key, value);       // exclusive
        } finally {
            lock.writeLock().unlock();
        }
    }
}

Readers do not block each other; a writer blocks everyone. This pays off only when reads greatly outnumber writes, because the bookkeeping costs more than a plain lock otherwise.

Atomic classes

AtomicInteger counter = new AtomicInteger();

counter.incrementAndGet();          // atomic ++
counter.addAndGet(5);
counter.getAndSet(0);
counter.updateAndGet(n -> n * 2);
counter.accumulateAndGet(10, Integer::sum);

boolean swapped = counter.compareAndSet(20, 30);   // only if it is still 20

How they work

read the current value
compute the new value
compare-and-set: if the value is still what we read, store the new one
otherwise start again

This is compare and swap, a single processor instruction. No thread ever blocks, which is why atomics outperform locks for a single variable. Under very high contention the retry loop can spin, and that is what LongAdder addresses by keeping per thread cells and summing them on demand.

LongAdder hits = new LongAdder();
hits.increment();
System.out.println(hits.sum());     // far faster than AtomicLong under contention

AtomicReference for a compound value

record Stats(int count, long total) { }

AtomicReference<Stats> stats = new AtomicReference<>(new Stats(0, 0));

stats.updateAndGet(current ->
        new Stats(current.count() + 1, current.total() + value));

An immutable record swapped atomically keeps two related fields consistent without any lock. The update function may run more than once, so it must be free of side effects.

Choosing between them

Common mistakes

• Not unlocking in a finally block.
• Unlocking a lock the thread does not hold, which throws.
• Using a read write lock where reads and writes are balanced, and losing performance.
• Assuming a sequence of atomic calls is itself atomic.
• Writing a side effecting function inside updateAndGet, which may be retried.
• Using a fair lock everywhere by default.

Best practices

• Prefer synchronized for straightforward exclusion; reach for a Lock when you need what it adds.
• Always unlock in finally.
• Use atomics for single variables and immutable records inside AtomicReference for related fields.
• Use LongAdder for high frequency counters.
• Keep update functions pure.
• Prefer the concurrent collections over locking a plain one.

Practice

1. Rewrite a synchronised counter using AtomicInteger and compare the code.
2. Why must unlock be in a finally block?
3. Implement a bounded buffer with two conditions and explain why one is not enough.
4. When does a read write lock actually pay for itself?
5. Use compareAndSet to implement a value that can only ever increase.

Conclusion

Explicit locks add timeouts, interruption, fairness and multiple conditions at the cost of manual unlocking. Atomic classes give lock free updates to a single variable. Use the simplest tool that meets the requirement, and let the concurrent collections do the work where they can.