Safe sharing: atomics, locks and concurrent collections

In thread synchronization you fixed a shared counter with synchronized: one lock, and every thread waits its turn. That works, but it is a blunt tool. The package java.util.concurrent has sharper ones, each shaped for one common job: a counter that never loses an update, a map that many threads can fill at once, a lock you can hold in your hand, and a way to wait until other threads are ready. This lesson takes them one at a time, then looks at the bug that locks bring with them, the deadlock.

One lock for everything is a blunt tool#

A synchronizedmethod takes the object's lock for the whole method. Every other thread that wants any synchronized method of that object waits in line, even when all it wants is to add one to a number. The program is correct, but the threads spend their time queuing. And a lock you cannot see is a lock you cannot test: you cannot ask “is it free?”, or give up after a second of waiting.

The concurrency package answers each of those needs with its own class. Here is the map of this lesson:

Atomic variables: a counter with no lock#

Start with the bug from thread synchronization. Four threads each add one to a shared int, a hundred thousand times. The total should be 400,000.

count = 133357      (eight runs on one laptop gave 133357, 127496,
                     141571, 128977, 159924, 123362, 153370 and 201695)

Eight runs, eight different wrong answers, all far below 400,000. Now change one thing: make the counter an AtomicInteger (from java.util.concurrent.atomic) and call count.incrementAndGet() in place of count++.

count = 400000      (every run)

Every run prints count = 400000. An atomic operation is one that happens as a single step that no other thread can split: the read, the add and the write of incrementAndGet happen together, so no update is lost. And there is no synchronizedanywhere. The processor itself has an instruction for “change this number, but only if nobody else changed it first”, and the atomic classes are built on it.

The methods you will use#

Each method name says what it does and in which order. incrementAndGet adds one and then gives you the new value; getAndIncrement gives you the old value and then adds one. Step through and watch the value in the memory view.

It prints 1, 1, 2, 12 and 24. new AtomicInteger() starts at 0. addAndGet(10) adds any amount, and updateAndGet applies a function to the current value, all as one step each. AtomicLong has the same methods for a long, AtomicBoolean holds a boolean, and AtomicReference holds a reference to any object.

getAndIncrement hands back the old value, 100, and the counter becomes 101. incrementAndGet makes it 102 and hands back 102. Read the name left to right: get, then increment; or increment, then get.

compareAndSet: change it only if nobody else has#

Every atomic method is built from one idea, compareAndSet(expected, newValue): “if the value is still expected, set it to newValue and return true; if someone changed it, change nothing and return false.” You can use it yourself for any update that is more than adding. Here is the ticket booth from thread synchronization, which must never sell a seat that is not there, written with no lock at all:

It prints true true false and seats left: 0. Read bookas a thread would. It reads how many seats are left. If there are none, it gives up. Otherwise it says “I saw left; if it is still left, make it one less.” If another thread took a seat in between, the value is no longer left, compareAndSetrefuses, and the loop reads the new number and tries again. A seat can never be sold twice, because only one thread's compareAndSet can succeed for each value.

Key idea

An atomic class makes one variable safe on its own, with no lock. compareAndSet is the tool underneath: change the value only if it is still what you last saw, and retry if it is not.

ConcurrentHashMap: a map many threads can share#

A plain HashMap was never meant to be changed by two threads at once. Four voting booths below each count 100,000 votes into one shared map, so every drink should end with 100,000.

Exception in thread "Thread-0" java.util.ConcurrentModificationException
	at java.base/java.util.HashMap.merge(HashMap.java:1394)
	at Main.lambda$main$0(Main.java:12)
	at java.base/java.lang.Thread.run(Thread.java:1516)
{coffee=53668, juice=53951, tea=53052, water=48965} total 209636

(ten runs gave totals from 144083 to 244666, and in seven of them
at least one booth's thread died with the exception above)

Two kinds of damage. Votes vanish, the same lost update as before, now inside the map. And sometimes HashMap notices that it was changed while it was in the middle of a merge and throws ConcurrentModificationException, which kills that booth's thread and every vote it had left to count. Change only the line that creates the map:

{coffee=100000, juice=100000, tea=100000, water=100000} total 400000      (every run)

Every run counts all 400,000 votes. ConcurrentHashMap is a Map like any other, so nothing else in the program changes. Inside, it is built so that many threads can read at the same time and threads writing to different parts of the table do not wait for each other, and each of its methods, merge included, happens as one atomic step.

merge, compute and friends#

The methods that change a value based on the old one are the ones that matter when threads share a map, because each is a single step. Step through and watch the entries appear.

It prints 3 1 null and {coffee=1, juice=11, tea=3, water=0}. merge(key, 1, Integer::sum) puts 1 for a new key and adds 1 to an existing one. putIfAbsent adds a key only if it is missing. compute gives you the key and its current value (or null) and stores whatever you return. The TreeMap copy is only there to print the entries in a fixed order.

A safe map does not make two steps safe#

Each method of a ConcurrentHashMap is atomic on its own. Two calls in a row are not. Here the booths count with a check followed by an act, on the safe map:

{coffee=70041, juice=69230, tea=78596, water=70408} total 288275

(six runs gave totals from 284123 to 298912, with no exception)

No crash this time, and still more than a hundred thousand votes lost. Between one booth's get and its put, another booth can do its own get, put, and both write the same new number. That is the check-then-act race from thread synchronization again. The fix is to let the map do the whole update in one call: merge, compute, computeIfAbsent or putIfAbsent.

ReentrantLock: a lock you hold in your hand#

Sometimes the thing to protect is several steps over several variables, which no single atomic variable can cover. synchronized does that job. ReentrantLock, from java.util.concurrent.locks, does the same job with the lock as an object you can see and ask questions of. It is always used in the same shape:

count = 400000      (every run)

lock() waits until the lock is free and takes it. The work goes in a try, and unlock() goes in its finally, so the lock is given back even if the work throws an exception. Forget the finally, and one exception leaves the lock taken forever: every other thread that wants it waits for good.

What reentrant means#

A thread that already holds the lock can take it again without waiting for itself. The lock counts how many times its owner has taken it, and it is free only when the count is back to 0. That is why a locked method can call another locked method of the same object. Step through and watch the hold count in the memory view.

It prints transfer holds: 1, withdraw holds: 2 and 70, locked: false. Inside withdraw the same thread holds the lock twice; each unlock takes one hold away, and after the second the lock is free. A lock that was not reentrant would make withdraw wait for a lock its own thread holds, forever. synchronized is reentrant in the same way.

CountDownLatch: wait until the others are ready#

A shop app loads its menu, its prices and its stock on three threads at once, and must not open until all three are done. A CountDownLatch is a counter that threads count down and other threads wait on. new CountDownLatch(3) starts at 3; each loader calls countDown() when it finishes; await() blocks until the count reaches 0.

Waiting for 3 loaders...
Loaded menu
Loaded stock
Loaded prices
All loaded. The shop opens.

The loaders finish in order of how long they sleep (100, 200 and 300 milliseconds), so the menu comes first and the prices last, and only then does main get past await(). Here is the latch on its own, counted down by one thread so you can step through it:

A latch is used once. When it reaches 0 it stays open, further countDown() calls do nothing, and there is no way to wind it back up. Make a new one for the next round.

Deadlock: everyone waiting for everyone#

Locks bring a bug of their own. Ada and Ben are two threads, and each needs two locks, a fork and a knife, to do its work. Ada takes the fork first; Ben takes the knife first. Try it below: step each diner yourself, or play “Take turns”.

If Ada takes the fork and Ben takes the knife before either reaches for the second tool, each now holds what the other needs, and each will wait until the other lets go. Neither ever will. That is a deadlock. Here is the same thing in Java, with real threads:

Ada has the fork
Ben has the knife

(and then nothing: the program never ends, and nothing is printed to say why)

The pause() makes the bad timing happen every time, so you can see it; in a real program the same timing happens rarely, which makes deadlocks hard to find. The program does not crash and prints no error. It just stops making progress, and you end it with Ctrl+C.

Finding a deadlock with jstack#

The JDK comes with a tool that looks inside a running Java program. While the program hangs, run jps in another terminal to list running Java programs with their process ids, then jstack with the id. At the end of its report:

It names both threads, which is why they were given names in the constructor, and says exactly who holds what and who waits for what. The lines it cut (shown as ...) give each thread's stack with the line numbers of the two synchronized blocks.

The fix: everyone takes the locks in the same order#

Switch the lab above to “Same order” and play “Take turns” again. Now both diners reach for the fork first. Whoever gets the fork can always get the knife, because the other diner cannot be holding the knife without the fork. The other one simply waits its turn. In the Java program, that means Ben's outer block becomes synchronized (fork) and his inner one synchronized (knife):

Ada has the fork
Ada eats
Ben has the fork
Ben eats

All six runs finished, with Ada first because her thread starts first. (Ben could win the fork instead, and then he would eat first; either way, both eat.)

Key idea

A deadlock needs threads that hold one lock while waiting for another, in a circle. Take every set of locks in one agreed order, and the circle cannot form.

Three more habits keep deadlocks away:

• Hold a lock for as short a time as you can, and never wait for something slow (a file, the network, the user) while holding one.
• Do not call code you do not control, such as a method passed in by someone else, while holding a lock: it might take locks of its own.
• When the order cannot be fixed, use tryLock with a timeout, and if the second lock does not come, let go of the first and try again later.

The easiest safety: data that never changes#

Every problem on this page comes from threads changing shared data. Data that nobody can change needs no protection at all: any number of threads can read it at once. A record with only immutable parts is like that. The one trap is a list inside it, which the outside world could still change, so the record makes its own unchangeable copy.

It prints [Ada, Ben] [Ada, Ben, Cy] and A Team cannot be changed. Adding Cy to the original list does not reach the team, because List.copyOf made a separate copy, and that copy refuses every change. A Team can be handed to a hundred threads with no lock. When something must change, make a new object with the new values, as records encourage, and share the new one.

Which tool for which job#

1import java.util.concurrent.atomic.AtomicInteger;
2 
3public class Main {
4    public static void main(String[] args) {
5        TicketMachine machine = new TicketMachine();
6        System.out.println(machine.nextTicket() + " " + machine.nextTicket() + " " + machine.nextTicket());
7        System.out.println("Next up: " + machine.peek());
8        System.out.println(machine.nextTicket());
9    }
10}
11 
12class TicketMachine {
13    private final AtomicInteger last = new AtomicInteger(0);
14 
15    int nextTicket() {
16        // TODO: add 1 to last and return the new value, in one atomic step
17        return 0;
18    }
19 
20    int peek() {
21        // TODO: the number the next call to nextTicket() will return, without taking it
22        return 0;
23    }
24}

Further reading#

• The java.util.concurrent package in the Java SE 25 API documentation, with an overview of every tool
• The java.util.concurrent.atomic package, with AtomicInteger, LongAdder and how compareAndSet behaves
• ConcurrentHashMap in the Java SE 25 API documentation
• Deadlock, from Oracle's Java Tutorials