synchronized and monitors

the picture

a single-occupancy room with one chair (the monitor). the door opens from inside only. whoever's inside can stay as long as they like, and can even walk through inner doors of the same room without knocking again (reentrancy). everyone else queues outside the door (the entry set). there's a second waiting area too, for people who stepped out to wait for something specific (the wait set). that one belongs to the next chapter.

the counter, fixed

synchronized on a method locks this for the whole body. here's last chapter's race, done right:

class Counter {
    private int count;
    synchronized void increment() { count++; }
    synchronized int get() { return count; }
}
 
void main() throws InterruptedException {
    Counter c = new Counter();
    Runnable work = () -> {
        for (int i = 0; i < 1_000_000; i++) c.increment();
    };
    Thread a = new Thread(work);
    Thread b = new Thread(work);
    a.start();
    b.start();
    a.join();
    b.join();
    IO.println("count = " + c.get());
}

count = 2000000

notice get() is synchronized too. that's not decoration. a lock does two jobs:

1. mutual exclusion: only one thread inside at a time, so compound actions can't interleave.
2. visibility: everything a thread wrote before releasing a monitor is visible to the next thread that acquires the same monitor. an unsynchronized get() gets neither, and is allowed to return a stale value forever. the rules behind that are the java memory model.

what actually gets locked

a synchronized method is just shorthand. the two forms on each row below are identical:

so the question "are these thread-safe together?" is always "do they lock the same object?". pick a call for each thread:

class Counter {
    private int n;
    synchronized void inc()          { n++; }      // locks this
    static synchronized void reset() { ... }       // locks Counter.class
    int get()                        { return n; } // locks nothing
}
Counter a = new Counter(), b = new Counter();

lock objects are per-object, not per-class and not per-method. two threads in two different synchronized methods of the same object still exclude each other (same this). two threads in the same method of two different objects don't.

reentrancy

a thread that owns a monitor can enter it again. the monitor keeps a hold count, and only the last exit releases it. without that, this would deadlock against itself:

class Account {
    private int balance = 100;
 
    synchronized void withdraw(int amount) {
        if (canWithdraw(amount)) {   // another synchronized method, same monitor
            balance -= amount;
        }
    }
    synchronized boolean canWithdraw(int amount) { return balance >= amount; }
    synchronized int balance() { return balance; }
}
 
void main() {
    Account acc = new Account();
    acc.withdraw(30);
    IO.println(acc.balance());
}

70

withdraw owns acc's monitor, calls canWithdraw, which wants the same monitor, and just walks in. recursion and overriding methods that call super.method() work the same way. this check-and-act is also the fix for last chapter's overdraft: both halves happen under one lock.

what the JVM does with it

a synchronized block compiles to two bytecodes, monitorenter and monitorexit, plus a hidden exception handler that releases the monitor if the block throws. you can never forget to unlock:

 6: monitorenter
 7: aload_0
 8: dup
 9: getfield      #13    // Field count:I
12: iconst_1
13: iadd
14: putfield      #13    // Field count:I
17: aload_1
18: monitorexit          ← normal exit
19: goto          27
22: astore_2
23: aload_1
24: monitorexit          ← exit when an exception is thrown
25: aload_2
26: athrow
Exception table:
   from    to  target type
      7    19    22   any

a synchronized method doesn't use those at all: it just has the ACC_SYNCHRONIZED flag, and the JVM does the same thing around the call.

the gotchas

synchronized can't time out, can't be interrupted while waiting, and can't be tried without blocking. when you need any of those, that's what ReentrantLock is for.