通过反射打破JIT优化

Question

在处理高度并发的单例类的单元测试时，我偶然发现了以下奇怪的行为（在JDK 1.8.0\U 162上测试）：

private static class SingletonClass {
    static final SingletonClass INSTANCE = new SingletonClass(0);
    final int value;

    static SingletonClass getInstance() {
        return INSTANCE;
    }

    SingletonClass(int value) {
        this.value = value;
    }
}

public static void main(String[] args) throws NoSuchFieldException, IllegalAccessException {

    System.out.println(SingletonClass.getInstance().value); // 0

    // Change the instance to a new one with value 1
    setSingletonInstance(new SingletonClass(1));
    System.out.println(SingletonClass.getInstance().value); // 1

    // Call getInstance() enough times to trigger JIT optimizations
    for(int i=0;i<100_000;++i){
        SingletonClass.getInstance();
    }

    System.out.println(SingletonClass.getInstance().value); // 1

    setSingletonInstance(new SingletonClass(2));
    System.out.println(SingletonClass.INSTANCE.value); // 2
    System.out.println(SingletonClass.getInstance().value); // 1 (2 expected)
}

private static void setSingletonInstance(SingletonClass newInstance) throws NoSuchFieldException, IllegalAccessException {
    // Get the INSTANCE field and make it accessible
    Field field = SingletonClass.class.getDeclaredField("INSTANCE");
    field.setAccessible(true);

    // Remove the final modifier
    Field modifiersField = Field.class.getDeclaredField("modifiers");
    modifiersField.setAccessible(true);
    modifiersField.setInt(field, field.getModifiers() & ~Modifier.FINAL);

    // Set new value
    field.set(null, newInstance);
}

main（）方法的最后两行在INSTANCE的值上不一致-我猜JIT完全摆脱了该方法，因为该字段是静态final。删除final关键字可以使代码输出正确的值。

撇开你对单例的同情（或缺乏同情）不谈，暂时忘记像这样使用反射是在自找麻烦——我的假设是正确的吗？JIT优化是罪魁祸首？如果是这样的话，那些仅限于静态的最终领域吗？

Answer 1

从字面上理解你的问题，“......我的假设是正确的，因为JIT优化是罪魁祸首吗？”，答案是肯定的，在这个特定示例中，JIT优化很可能对这种行为负责。

但是，由于更改静态final字段完全不符合规范，因此还有其他类似的事情可以破坏它。E、 g.JMM没有定义这种更改的内存可见性，因此，其他线程是否或何时注意到这种更改是完全不确定的。他们甚至不需要一致地注意到它，即他们可以使用新值，然后再次使用旧值，即使在存在同步原语的情况下也是如此。

尽管如此，这里很难将JMM和优化器分开。

您的问题“…这些仅限于静态最终字段吗？”很难回答，因为优化当然不限于静态最终字段，但非静态最终字段的行为（例如非静态最终字段）是不同的，并且在理论和实践之间也存在差异。

对于非静态的final字段，在某些情况下允许通过反射进行修改。这一点可以通过以下事实来说明，即设置可访问性（true）足以使此类修改成为可能，而无需侵入字段实例来更改内部的修改器字段。

规范规定：

在某些情况下，如反序列化，系统需要在构建后更改对象的final字段<可以通过反射和其他依赖于实现的方式更改代码>最终字段。唯一具有合理语义的模式是构建对象，然后更新对象的最终字段。在对象的最终字段的所有更新完成之前，不应使对象对其他线程可见，也不应读取最终字段。在设置了最终字段的构造函数末尾，以及通过反射或其他特殊机制对最终字段进行每次修改后，都会立即冻结最终字段。

…

另一个问题是，该规范允许对最终字段进行积极的优化。在一个线程中，允许使用构造函数中未发生的对最终字段的修改来重新排序最终字段的读取。

class A {
    final int x;
    A() { 
        x = 1; 
    } 

    int f() { 
        return d(this,this); 
    } 

    int d(A a1, A a2) { 
        int i = a1.x; 
        g(a1); 
        int j = a2.x; 
        return j - i; 
    }

    static void g(A a) { 
        // uses reflection to change a.x to 2 
    } 
}

在d方法中，允许编译器自由地重新排序x的读取和对g的调用。因此，new A（）. f（）可以返回-1、0或1。

在实践中，确定在不违反上述法律场景的情况下可以进行积极优化的正确位置是一个悬而未决的问题，因此除非指定了-XX： TrustFinalNonStaticFields，否则HotSpot JVM不会优化非静态最终字段与静态最终字段相同的方式。

当然，当您没有将字段声明为final时，JIT不能假定它永远不会更改，尽管在没有线程同步原语的情况下，它可能会考虑在其优化的代码路径中发生的实际修改（包括反射的修改）。因此，它仍然可以积极地优化访问，但前提是读取和写入仍然按照执行线程中的程序顺序进行。因此，只有在没有适当的同步构造的情况下，从不同的线程查看优化时，您才会注意到它。