The final keyword in Java enforces immutability at compile time and enables runtime optimizations by restricting reassignment of variables, methods, and classes; 2. For final fields, the Java Memory Model guarantees safe publication without synchronization, ensuring other threads see correctly initialized values due to write barriers and prevention of instruction reordering; 3. The JVM inserts memory fences after constructor completion for final fields, preventing caching issues across threads and eliminating the need for volatile or synchronized for safe publication; 4. Compiler optimizations include constant folding and inlining for static final constants, reducing runtime field access; 5. Escape analysis benefits from final fields, enabling stack allocation of objects when immutability is assured; 6. Final methods and classes allow devirtualization, enabling aggressive JIT inlining since method overriding is prohibited; 7. However, final only makes the reference immutable, not the object itself, so true immutability requires final fields pointing to immutable objects and no state-modifying methods; 8. The use of final provides both concurrency safety and performance improvements by allowing the JVM to make stronger assumptions about program behavior, making it a powerful mechanism beyond mere syntactic restriction.

The final keyword in Java is more than just a way to prevent reassignment—it influences how the Java compiler and JVM behave, and it has implications at both the language and runtime levels. Understanding its internals helps explain not only what final does, but why it matters for performance, concurrency, and memory model guarantees.

What final Actually Does (Under the Hood)

At its core, final is a compile-time and runtime enforcement mechanism that restricts mutation and enables certain optimizations. It can be applied to variables, methods, and classes, each with different effects.

When applied to variables, final ensures that:

• The variable must be assigned exactly once.
• Once assigned, it cannot be reassigned.

For fields, this becomes especially important in the context of object construction and thread safety.

public class Example {
    final int value;

    public Example(int value) {
        this.value = value; // Must be assigned once
    }
}

The compiler enforces that value is assigned in all constructors. If you try to assign it again later, it’s a compile-time error.

But the real magic happens at the JVM level.

final Fields and the Java Memory Model

One of the most important internal aspects of final is how it interacts with the Java Memory Model (JMM), especially in multi-threaded environments.

According to the JMM:

A properly constructed object with final fields guarantees that those fields are safely published—meaning other threads will see their correctly initialized values, without needing additional synchronization.

This is achieved through special rules around final field semantics during object construction.

How It Works Internally

1. Write Barrier on Final Field Assignment
   When a final field is assigned during construction, the JVM inserts a write barrier (a memory fence) after the constructor finishes. This prevents reordering of writes to final fields with respect to the assignment of the object reference to other threads.

2. No Caching of Final Fields Across Threads
   Unlike regular fields, threads are guaranteed to see the initial value of a final field, even if they access the object via data races (which are technically allowed for final fields as long as the object is safely published).

3. No Need for volatile or synchronized for Safe Publication
   If an object’s final fields are set during construction and the object reference doesn’t escape during construction (i.e., no this reference leaked), then other threads will see the correct values—no extra synchronization needed.

// Thread-safe due to final field semantics
public class ImmutablePoint {
    public final int x, y;

    public ImmutablePoint(int x, int y) {
        this.x = x;
        this.y = y;
    }
}

Even if another thread gets a reference to an ImmutablePoint without synchronization, it will see the correct x and y.

This is a critical optimization used in classes like String, Optional, and other immutable types.

Compiler Optimizations Enabled by final

The final keyword gives the compiler and JIT more freedom to optimize code.

1. Constant Folding and Inlining

If a final variable is a compile-time constant (e.g., static final int MAX = 100;), the compiler may:

• Inline the value directly into calling code.
• Eliminate the field entirely (no field access at runtime).

static final int TIMEOUT = 5000;
// Used as: Thread.sleep(TIMEOUT);
// May become: Thread.sleep(5000); at compile time

This reduces memory access and improves performance.

2. Escape Analysis and Stack Allocation

The JVM uses escape analysis to determine if an object can be allocated on the stack instead of the heap. final fields help because their immutability makes it easier for the JVM to prove that the object’s state won’t be modified or observed externally.

3. Devirtualization

For final methods and classes, the JIT can inline method calls because there’s no possibility of overriding.

final class MathUtils {
    static int add(int a, int b) {
        return a   b;
    }
}

Since MathUtils can’t be subclassed, any call to add() can be inlined aggressively.

Similarly, a final method in a non-final class prevents override, allowing similar optimizations.

final vs. Immutable Objects

It’s important to note: final on a reference doesn’t make the object immutable.

final List<String> list = new ArrayList<>();
list.add("item"); // Allowed! The *reference* is final, not the object

The final keyword only prevents reassigning list. It doesn’t freeze the object itself.

True immutability requires:

• final fields.
• Those fields referring to immutable objects (e.g., String, Integer) or defensive copies.
• No methods that modify internal state.

Internals Summary: What Happens at Each Level

Practical Implications

• Use final on fields whenever possible—especially in immutable classes.
• It’s not just about intent; it provides real thread-safety guarantees.
• Combine with private and proper construction to ensure encapsulation.
• Don’t assume final = immutable—check object mutability too.

Basically, final isn’t just a restriction—it’s a contract that enables the JVM to make stronger assumptions about your code, leading to safer concurrency and better performance. The internals are subtle but powerful.

The above is the detailed content of The Internals of the Java `final` Keyword. For more information, please follow other related articles on the PHP Chinese website!