Question: The Oracle [lesson on concurrency](https://docs.oracle.com/javase/tutorial/essential/concurrency/syncmeth.html) states:

> 
> Second, when a synchronized method exits, it automatically establishes a happens-before relationship with any subsequent invocation of a synchronized method for the same object.
> 
> 
> 

This seems to be trivially true, since "subsequent" implies that it happens after the synchronized method exits. This statement seems to be true of un-synchronized methods as well. What am I missing?

Answer: 
You are missing that "subsequent" has nothing to do with the passage of time; it has to do only with where the method invocations appear in the *synchronization order*. This is the essential difference between *linearizability* (strict ordering by wall-clock time, not guaranteed by the Java Memory Model) and *sequential consistency* ("consistent with some ordering", guaranteed for data race-free programs). The phrase "happens before" is also deceptive because it doesn't imply time ordering, either. 

For unsynchronized methods there is simply no ordering because their invocations don't appear in the synchronization order.

As you very nicely summarize in the comments:

> 
> Every execution has some order on synchronization actions which may or may not be the same as the "actual" execution order. However, this synchronization order is consistent with program order of individual threads. Moreover, if exiting a synchronized method occurs earlier in the synchronization order than entering a synchronized method on the same object, then all reads in the entered method see writes in the exited method.
> 
> 
>
Suppose there is a non-volatile field `f` that holds value *v*, and suppose that thread A updates field `f` with value *w*, and suppose that thread B subsequently reads field `f`.

You might be surprised to learn that there is *not* any happens before relationship between the update and the read. The Java Language Specification (JLS) allows thread B to get *v* when it reads the field even though, according to the wall clock, the read happened subsequent to the update.

Everything that happens within one thread is required to happen in *program order*. If the code executed by thread A looks like it updates some field, and then later reads the field, then the JLS requires that the read get the value that was written (i.e., the write "happens before" the read).

There is no such requirement when the read and the write happen in different threads. In general, events that happen in one thread are independent of events that happen in another thread *except* in certain special cases. Entering and leaving `synchronized` blocks are one of those special cases.

When the JLS says that leaving a synchronized block "happens before" a subsequent entry into a block synchronized on the same object, it means that the happens before relationship is true *even when the events happen in different threads.*