How Java’s As‑If‑Serial Semantics Keep Single‑Thread Results but Break Multithreaded Guarantees

Reordering Conditions

When a program runs, processors and compilers may reorder instructions to improve performance, but two rules must be obeyed: (1) the result of a single‑threaded execution must not change, and (2) instructions that have data dependencies cannot be reordered.

As‑If‑Serial Semantics

The as‑if‑serial rule states that any optimization, including reordering, must not alter the observable result of a program. This rule applies only to single‑threaded code; it does not guarantee correctness in multithreaded contexts.

Simple Single‑Thread Example

int a = 1; // A
int b = 2; // B
int c = a + b; // C

Operations A and B are independent, while both depend on C. The compiler may reorder A and B arbitrarily, but C must remain after them, so the final result of c is always 3.

Happens‑Before Relations

In the example above the following happens‑before relations hold:

A happens‑before B

B happens‑before C

A happens‑before C

These relations are derived from program order and data dependencies, not from the actual execution order after reordering.

Exception Handling Edge Case

public class RecordExample1 {
    public static void main(String[] args) {
        int a = 1;
        int b = 2;
        try {
            a = 3; // A
            b = 1 / 0; // B (throws)
        } catch (Exception e) {
        } finally {
            System.out.println("a = " + a);
        }
    }
}

If the JVM were to reorder A and B, B would throw an exception before A executes, potentially changing the final value of a. To preserve as‑if‑serial semantics, the JIT inserts compensation code in the catch block (e.g., a = 3) so that the observable result remains the same even though the control flow is altered.

Impact on Multithreading

In multithreaded code the as‑if‑serial rule no longer protects correctness. Consider the classic volatile example:

public class RecordExample2 {
    int a = 0;
    boolean flag = false;
    public void writer() { // Thread A
        a = 1; // 1
        flag = true; // 2
    }
    public void read() { // Thread B
        if (flag) { // 3
            int i = a + a; // 4
        }
    }
}

Thread B may or may not see a = 1 because the writes to a and flag can be reordered; on x86 the write‑write reordering does not occur, but on other architectures it can, breaking the intended happens‑before relationship.

Furthermore, control dependencies (e.g., the if (flag) test) can be speculatively executed, leading to additional reordering complexities.

Conclusion

Instruction reordering respects program order and data dependencies in single‑threaded Java, guaranteeing the as‑if‑serial semantics. However, in multithreaded scenarios the same reordering can violate happens‑before guarantees, making explicit synchronization (e.g., volatile, locks) essential for correct concurrent behavior.

References

周志明, 《深入理解Java虚拟机》

方腾飞, 《Java并发编程的艺术》