.JAVA File Format – Threads and the memory model

synchronized

Every object has a monitor, a lock that one thread at a time can hold. A thread may lock a monitor it already holds again (it is re-entrant); it must unlock it as many times.

The lock is released however the block or method ends, including by an exception. Interface methods, constructors and initialisers cannot be synchronized, though they may contain synchronized blocks.

class Counter {
    private int count;
    synchronized void increment() { count++; }   // read, add and write as one step
    synchronized int get() { return count; }     // also synchronized, to see the latest value
}

wait, notify and interrupts

Every object also has a wait set (JLS 17.2), used through methods of Object by a thread that holds the object’s monitor (otherwise they throw IllegalMonitorStateException):

A waiting thread may also wake for no reason (a spurious wake-up), so the condition must be tested in a loop. Thread.interrupt() makes a waiting thread throw InterruptedException.

synchronized (queue) {
    while (queue.isEmpty()) {
        queue.wait();            // releases the lock while waiting
    }
    item = queue.remove();
}

Thread.sleep pauses without releasing any monitor, and Thread.yield hints that other threads may run; neither has any synchronisation effect, so a loop waiting on a non-volatile field may never see it change (JLS 17.3).

The memory model

Compilers and processors reorder reads and writes, and cache values, as long as each thread on its own cannot tell. Another thread can, so without synchronisation one thread may see another’s writes late, or in a different order. The memory model defines a partial order, happens-before: if a write happens-before a read of the same variable, the read sees that write or a later one (JLS 17.4.5).

volatile

A volatile field is read from and written to main memory in a single global order shared by all threads, and its writes happen-before its later reads. Everything a thread wrote before writing a volatile field is visible to a thread that then reads that field. Reads and writes of volatile long and double fields are atomic.

class Worker implements Runnable {
    private volatile boolean stopped;     // without volatile, run() might never see the change
    public void stop() { stopped = true; }
    public void run() {
        while (!stopped) doWork();
    }
}

volatile does not make compound actions atomic: count++ on a volatile field can still lose updates. Use synchronized or java.util.concurrent.atomic.AtomicInteger.

final fields

If an object’s constructor does not let this escape, every thread that obtains a reference to the object after the constructor finishes sees the values its constructor wrote to its final fields, and everything reachable through them as of that time, without any synchronisation (JLS 17.5). This is what makes immutable objects such as String safe to share. Fields that are not final have no such guarantee when the object is passed through a data race.

Changing a final field afterwards by reflection or other means is allowed only in special cases (such as deserialisation) and undermines the guarantee. Since Java 26 the JDK warns about such changes made through deep reflection, as a step towards forbidding them (JEP 500).

Word tearing and long and double

• Every field and array element is a separate variable: writing one byte of a byte[] never changes its neighbours, even on hardware that can only write whole words (JLS 17.6).
• Writes to non-volatile long and double variables may be split into two 32-bit halves, so another thread could see half of an old value and half of a new one (JLS 17.7). Reads and writes of references and of every other primitive type are always atomic. Most 64-bit JVMs do write 64-bit values atomically, but the language does not promise it.