The Lock Every Object Already Has

Every object in Java has a lock built into it. Not a special class: every object, going back to Object in Section 8.3. It is called a monitor, and until now you have been carrying one around on every object you have ever made without using it.

synchronized (lock) {
    counter++;
}

One thread at a time inside those braces, for that object. Everyone else waits, in the BLOCKED state from Section 14.2.

Verified, the same counter as last section:

synchronized counter: 200000 (wanted 200000)

Exact, every run.

There are three ways to write it, and two of them hide what is being locked.

Those last two are the same keyword and two different locks.

An instance method locks this, so each object has its own. A static method locks the Class object, because there is no instance, and there is exactly one of those per class in the method area from Section 13.1.

The lock is reentrant. A thread already holding it can take it again:

synchronized void outer() { inner(); }
synchronized void inner() { ... }

inner entered while holding the same lock

The monitor remembers which thread holds it and keeps a count. Entering again increases the count, leaving decreases it, and the lock is released at zero.

Without that, outer calling inner would wait forever for a lock it was already holding. It also makes inheritance work: an overridden synchronized method calling super would otherwise deadlock every time.

And a lock fixes visibility too. From the happens-before rules in Section 14.4:

Unlocking a monitor happens-before any later locking of the same monitor.

So everything a thread wrote before releasing is visible to the next thread that acquires. A lock is not only a queue. It is also a promise about what you will see when your turn comes.

That is the whole reason a lock fixes all three problems and volatile fixes two.

Answer from memory before opening the explanation. Then compare your rule with the answer and revisit the example if they differ.

1. `synchronized void update()` on an instance method. What object is being locked?

   Show the answer

   this. The instance the method was called on.

   Which means two different objects have two different locks, and two threads calling update() on two different instances never wait for each other. That is usually what you want and it is worth knowing rather than assuming.

   On a static method the lock is the Class object, MyClass.class, because there is no instance to lock. There is one of those per class, so all static synchronized methods of a class share one lock.

   Those are two different locks. A static synchronized method and an instance synchronized method can run at the same time, on the same data, protecting nothing.

2. Why can a synchronized method call another synchronized method on the same object without deadlocking?

   Show the answer

   Because the lock is reentrant. It remembers which thread holds it and keeps a count.

   A thread already holding the lock walks straight into another synchronized block on the same object and the count goes up. It is released only when the count reaches zero again.

   Without that, any synchronized method calling another one on the same object would wait forever for a lock it was already holding. Inheritance would make it worse, since an overridden method calling super would deadlock every time.

3. How does a lock fix visibility, when it looks like it only stops two threads running at once?

   Show the answer

   Because releasing a lock and acquiring it are a happens-before pair, from Section 14.4.

   When a thread releases a monitor, everything it wrote before that point is published. When the next thread acquires the same monitor, it sees all of it.

   So a lock is not only about taking turns. It is also a promise about what you will see when your turn comes, and that is why a lock fixes all three problems while volatile fixes two.

   It only works if both sides use the same lock. A thread reading without locking gets no promise at all, however careful the writer was.

Write each solution in VS Code, predict its result, and then run the checks. Reading an example does not replace implementing it.

4 exercises105 pointsabout 105 minutes

public class TwoKeys {
    static int shared = 0;
    int instanceField = 0;

    static synchronized void staticWay() { shared++; }
    synchronized void instanceWay() { shared++; }

    public static void main(String[] args) throws Exception {
        // TODO: one thread calling staticWay, one calling instanceWay on an object.
        //       Both update `shared`. Both say synchronized. Predict the total.
        // TODO: run it five times
        // TODO: fix it so both use the same lock. Two ways to do that.
        // TODO: say exactly which object each of the two methods locks
    }
}

public class Stuck {
    static final Object a = new Object();
    static final Object b = new Object();

    public static void main(String[] args) throws Exception {
        // TODO: thread 1 takes a then b. Thread 2 takes b then a.
        //       Put a small sleep between the two acquisitions so it happens reliably.
        // TODO: after two seconds, print both threads' states from main
        // TODO: take a thread dump with jstack and read what it says
        // TODO: fix it by giving both threads the same lock ORDER
        // TODO: try to interrupt the deadlocked threads. Does it help?
    }
}

public class WhoseLock {
    // TODO: three classes that each lock something shared by accident:
    //   one that does synchronized (this)
    //   one that does synchronized ("key")
    //   one that does synchronized (Integer.valueOf(1))

    public static void main(String[] args) throws Exception {
        // TODO: show that two UNRELATED classes locking "key" block each other
        // TODO: show the same for Integer.valueOf(1), and say why 1000 behaves differently
        // TODO: show outside code taking the lock of an object that used
        //       synchronized (this), and holding it
        // TODO: rewrite all three with a private lock object
    }
}

import java.util.*;

public class TooLong {
    static final Map<String, String> cache = new HashMap<>();

    static synchronized String slowWay(String key) {
        String hit = cache.get(key);
        if (hit != null) return hit;
        String value = expensive(key);        // 50 ms, and it touches nothing shared
        cache.put(key, value);
        return value;
    }

    static String expensive(String key) {
        try { Thread.sleep(50); } catch (Exception e) { }
        return key.toUpperCase();
    }

    public static void main(String[] args) throws Exception {
        // TODO: eight threads asking for eight DIFFERENT keys. Time it.
        // TODO: rewrite so the lock is held only around the map, not around expensive().
        //       Time it again.
        // TODO: what new problem did you just create, and is it acceptable?
        // TODO: try ConcurrentHashMap.computeIfAbsent instead. Time that too.
    }
}