Is there a limit to overriding final static field

问题:

I have been faced in some of my Unit test with a strange behaviour with Reflection on final static field. Below is an example illustrating my issue.

I have a basic Singleton class that holds an Integer

public class BasicHolder {
    private static BasicHolder instance = new BasicHolder();

    public static BasicHolder getInstance() {
        return instance;
    }

    private BasicHolder() {
    }

    private final static Integer VALUE = new Integer(0);

    public Integer getVALUE() {
        return VALUE;
    }

}

My test case is looping and setting through Reflection the VALUE to the iteration index and then asserting that the VALUE is rightfully equal to the iteration index.

class TestStaticLimits {
    private static final Integer NB_ITERATION = 10_000;

    @Test
    void testStaticLimit() {

        for (Integer i = 0; i < NB_ITERATION; i++) {
            setStaticFieldValue(BasicHolder.class, "VALUE", i);
            Assertions.assertEquals(i, BasicHolder.getInstance().getVALUE(), "REFLECTION DID NOT WORK for iteration "+i);
            System.out.println("iter " + i + " ok" );

        }
    }

    private static void setStaticFieldValue(final Class obj, final String fieldName, final Object fieldValue) {
        try {
            final Field field = obj.getDeclaredField(fieldName);
            field.setAccessible(true);
            final Field modifiersField = Field.class.getDeclaredField("modifiers");
            modifiersField.setAccessible(true);
            modifiersField.setInt(field, field.getModifiers() & ~Modifier.FINAL);
            field.set(null, fieldValue);
        } catch (NoSuchFieldException | IllegalAccessException e) {
            throw new RuntimeException("Error while setting field [" + fieldName + "] on object " + obj + " Message " + e.getMessage(), e);
        }
    }

}

The result is quite surprising because it's not constant, my test fails around iteration ~1000 but it never seems to be always the same.

Anyone has already faced this issue ?

回答1:

The JLS mentions that modifying final fields after construction is problematic - see 17.5. final Field Semantics

Fields declared final are initialized once, but never changed under normal circumstances. The detailed semantics of final fields are somewhat different from those of normal fields. In particular, compilers have a great deal of freedom to move reads of final fields across synchronization barriers and calls to arbitrary or unknown methods. Correspondingly, compilers are allowed to keep the value of a final field cached in a register and not reload it from memory in situations where a non-final field would have to be reloaded.

and 17.5.3. Subsequent Modification of final Fields:

Another problem is that the specification allows aggressive optimization of final fields. Within a thread, it is permissible to reorder reads of a final field with those modifications of a final field that do not take place in the constructor.

In addition to that, the JavaDocs of Field.set also include a warning about this:

Setting a final field in this way is meaningful only during deserialization or reconstruction of instances of classes with blank final fields, before they are made available for access by other parts of a program. Use in any other context may have unpredictable effects, including cases in which other parts of a program continue to use the original value of this field.

It seems that what we are witnessing here is the JIT taking advantage of the reordering and caching possibilities granted by the Language Specification.

回答2:

It's because of the JIT optimization. To prove this, disable it using the following VM option:

-Djava.compiler=NONE

In this case all 10_000 iterations will work.

Or, exclude the BasicHolder.getVALUE method from being compiled:

-XX:CompileCommand=exclude,src/main/BasicHolder.getVALUE

What actually happens under the hood is that after nth iteration, the hot method getVALUE is being compiled and static final Integer VALUE is being aggressively optimized (this is really the just-in-time constant¹). From this point, the assertion starts to fail.

The output of the -XX:+PrintCompilation with my comments:

val 1       # System.out.println("val " + BasicHolder.getInstance().getVALUE());
val 2
val 3
...
922  315    3    src.main.BasicHolder::getInstance (4 bytes)   # Method compiled
922  316    3    src.main.BasicHolder::getVALUE    (4 bytes)   # Method compiled
...
val 1563    # after compilation
val 1563
val 1563
val 1563
...

---

^{1 - JVM Anatomy Park: Just-In-Time Constants.}