Thread creation and synchronization

In the introduction to threads you started several threads at once and watched their output come out in a different order on each run. That was harmless while each thread minded its own business. Trouble starts when two threads change the same data. This lesson shows the quiet bug that follows, and the keyword that prevents it. First, though, you need a way to make one thread wait for another.

Waiting for a thread: join#

Here is a worker built from a lambda. It counts to three, and then main prints that the worker is done. Read the output carefully.

main: the worker is done
worker: 1
worker: 2
worker: 3

main announced that the worker was done before the worker had printed a single line. start() only sets the worker going. main carried straight on to its println, and the worker got its first turn afterwards. The lines came out in this order in each of 70 runs, but nothing promises even that.

To make one thread wait for another, call join() on the thread to wait for. worker.join() pauses the thread that calls it, main here, until worker has finished its run().

worker: 1
worker: 2
worker: 3
main: the worker is done

Now the order is the same on every run. The worker prints its three lines and finishes, and only then does join() return and let main print. join() can throw a checked exception, InterruptedException, which the next section explains, so main now declares throws InterruptedException.

Key idea

t.join() makes the calling thread wait until thread thas finished. Call it whenever one thread needs another thread's work to be complete.

Pausing a thread: sleep#

Thread.sleep(ms) pauses the thread that calls it for that many milliseconds, then lets it carry on. While it sleeps, the thread uses no processor time. It is how you make a timer tick once a second or wait a little before trying something again, and on this page it stands in for slow work. The visualizer runs this program, narrating each pause instead of waiting.

On a real JVM the lines appear one second apart. The text printed is the same.

InterruptedException#

Both sleep and join can throw InterruptedException, a checked exception. It means another thread called interrupt() on this one: a request to stop waiting and get on with something else. No program in this lesson interrupts a thread, but the compiler still makes you handle the exception. In main you can declare it with throws. Inside a job you cannot, because the run() of Runnable declares no checked exceptions, and that rule holds for a lambda too:

main declares throws InterruptedException, but that covers only the code of main itself. The lambda's body is the body of run(), so the sleep inside it needs its own try and catch. The jobs on the rest of this page have one.

The bug: two threads, one counter#

Now for the trouble. A shared Counter object has a field count and a method increment() that does count++. Two threads run the same job, each calling increment() 100,000 times, and main joins both before it prints. Two threads times 100,000 should make exactly 200,000.

Final count: 127868

This run printed 127868, so about 72,000 increments vanished. Other runs of the same program printed 110514, 154935 and 106326. Nothing crashed and no error was printed. The program gave a wrong answer and looked finished.

It does not even fail every time. In one batch of 100 runs, 87 printed a wrong total, no two of them the same, and 13 printed the correct 200000, because one thread happened to finish its work before the other got going. A program like this can pass a quick test and fail later.

Key idea

A race condition is when the result of a program depends on the exact timing of two or more threads, in a way you did not intend. The threads race to touch the same data, and who wins changes the answer.

Where did the updates go?#

The whole problem hides in one short line: count++. It looks like one step, but Java runs it as three: read the current value of count from memory, add one to that value, then write the result back to count. Between any two of those steps, the other thread can get a turn.

While a thread works through the three steps, it keeps the value it read in its own working copy, separate from countin memory. That copy is where updates go missing. Drive the two threads yourself: “Step A” and “Step B” choose which thread moves next, and the buttons at the bottom play three orders for you.

Play “Both read first”. A and B each read 0, each add one to their own copy, and each write 1. count++ ran twice and countis 1, because the second write landed on top of the first. Now play “A, then B”. B reads after A has written, so B starts from 1 and count ends at 2. The only difference is the order of the steps. In a real program the scheduler chooses that order, a little differently on every run, and 200,000 increments give it plenty of chances to choose a bad one.

An action that happens as one step that no other thread can split is called atomic. count++ is not atomic.

It prints 42, though two increments ran. Both threads read 41 before either one wrote, so both copies became 42. B wrote 42, then A wrote its own 42 over it. Open it in the playground and step through it to watch a, b and count.

The fix: one thread at a time with synchronized#

The race exists because two threads can be part-way through increment() at the same time. The fix is to forbid exactly that: while one thread is running increment() on an object, no other thread may enter increment() on that same object. It must wait its turn. The keyword that does this is synchronized.

Final count: 200000

One word changed: synchronized void increment(). In 50 runs, every one printed 200000. The read, the add and the write still happen as three steps, but no other thread can slip in between them, because only one thread at a time may be inside the method.

What synchronized does: a lock#

Picture a small room with one key hanging by the door. Every Java object has a key like this, called its lock (Java's documentation also calls it the object's monitor). To run a synchronizedmethod on an object, a thread must first take that object's lock. While it holds the lock, it runs the method. Any other thread that wants to run a synchronized method on the same object finds the key gone and waits by the door. When the first thread leaves the method, it hangs the key back up, and one waiting thread may take it and go in.

Key idea

synchronizedmakes a thread take the object's lock before it runs the code. Only one thread can hold a lock at a time, so the three steps of count++ can no longer be split by another thread.

Here is the stepper again, starting in its synchronized mode. Try to make B cut in.

Each thread now takes the counter's lock before its read and gives it back after its write. While A holds the lock, pressing “Step B” gets nowhere: B is blocked at the door. Whichever thread takes the lock first has written its result before the other one can read, so the second thread always starts from the first one's result, and count ends at 2 whatever order you press.

The lock belongs to the object, not to the method. Two Counter objects have two locks, so a thread incrementing one counter never waits for a thread incrementing the other. That is what you want: they share no data, so there is nothing to protect. Two more rules complete the picture. A thread that already holds a lock can call other synchronized methods on the same object without waiting for itself. And a static synchronizedmethod takes a lock that belongs to the class as a whole, shared by every call of that class's static synchronized methods.

Synchronizing a block#

Sometimes only part of a method touches shared data. Then you can lock just that part with a synchronized block, which names the object whose lock to take in parentheses. Here a bank account checks the amount without the lock, because the check only reads the parameter, and locks only the line that changes the balance:

Balance: 20000

Two threads each deposit 10 a thousand times, so the balance must end at 20000, and it does on every run. Inside a method, this is the object the method was called on, so synchronized (this) takes the same lock that a synchronized method would. In fact a synchronized method is shorthand for wrapping its whole body in synchronized (this) { ... }. getBalance() is synchronized too, because every read of shared data needs the lock, not only every write.

Check, then act#

count++ is one shape of race: read a value, change it, write it back. Another shape is just as common. A thread checks something, then acts on what it saw, and between the check and the act another thread changes the facts. Here a ticket booth has one seat left, and Ana and Ben try to buy it at the same moment:

Ana gets a seat
Ben gets a seat
Seats left: -1

There was one seat, and both of them got it. Each thread checked seatsLeft > 0, saw 1 and went on to take the payment, which the pause stands in for. By the time either one took the seat, the other had already passed the check. In a batch of 100 runs the seat was sold twice in 99, in either order. Five of those even printed Seats left: 0, because the two seatsLeft--lines are a read, a subtraction and a write, and they raced as well. In the one remaining run, Ben's thread happened to start late enough to find the seat already gone.

The fix is the same keyword. The check and the act have to happen under one lock, so buy becomes synchronized:

Ana gets a seat
Sorry Ben, sold out
Seats left: 0

Whoever takes the lock first now does the check, the payment and the sale before the other thread can even look. Ana won in every run here, because her thread was started first, but if Ben's thread reached the lock first, he would get the seat and Ana would hear “sold out”. Either way the seat is sold once. A sleeping thread keeps any lock it holds, so while Ana pays, Ben waits at the door.

Key idea

When a decision depends on shared data, the check and the action must happen under the same lock.

1public class Main {
2    public static void main(String[] args) {
3        Booth booth = new Booth(5);
4        booth.buy("Ana", 2);
5        booth.buy("Ben", 4);
6        booth.buy("Cleo", 3);
7        System.out.println("Seats left: " + booth.getSeatsLeft());
8    }
9}
10 
11class Booth {
12    private int seatsLeft;
13 
14    Booth(int seats) {
15        seatsLeft = seats;
16    }
17 
18    // TODO: make buy safe for two threads, then finish it
19    void buy(String name, int wanted) {
20    }
21 
22    synchronized int getSeatsLeft() {
23        return seatsLeft;
24    }
25}

The life of a thread#

A thread is not simply on or off. Over its life it moves through a handful of states, and Java has a name for each one. getState() returns a thread's current state as a value of the enum Thread.State.

This program catches a thread in four of them:

before start: NEW
inside run: RUNNABLE
while it sleeps: TIMED_WAITING
after join: TERMINATED

Before start() the thread is NEW. Inside its own run(), the thread asks for its own state and gets RUNNABLE, because it is running at that moment. main then sleeps for 100 milliseconds, so it looks while the thread is in the middle of its 500 millisecond sleep: TIMED_WAITING. After join() the thread has finished: TERMINATED. The sleeps make this timing reliable in practice, and the four lines came out the same in each of 80 runs, but nothing in Java promises it.

BLOCKED shows up at the ticket booth. This version of main starts Ana first, waits a moment, starts Ben, and looks at both of them while Ana is paying:

Ana is TIMED_WAITING
Ben is BLOCKED
Ana gets a seat
Sorry Ben, sold out

Ana is inside buy, asleep while she pays, so her state is TIMED_WAITING, and she still holds the booth's lock. Ben has reached buy and is waiting for that lock, so he is BLOCKED. When main then sits in ana.join(), its own state is WAITING. These lines too came out the same in each of 80 runs.

Further reading#

• Thread.State in the Java SE 25 API documentation, with the exact meaning of all six states
• The Thread class in the Java SE 25 API documentation, for join, sleep and interrupt
• Synchronization, from Oracle's Java Tutorials: thread interference, synchronized methods and locks (written for Java 8, and these basics have not changed)
• Threads and Locks, chapter 17 of the Java Language Specification, the precise rules behind synchronized and join