摘要：某個測試服務器試圖通過反射來修改變量的值，出現了時靈時不靈的現象。這個閾值隨時會變，只是測著玩的編譯是可以取消的，現在修改如下，在用反射設值后，再次執行萬次直接取值現在的執行結果又是了。結論不要修改變量，會出問題的關于編譯期優化的更多知識

某個測試服務器試圖通過反射來修改static final變量的值，出現了時靈時不靈的現象。

開發環境無法重現。這是怎么回事呢？

一般認為，static final常量會被編譯器執行內聯優化，即它的值會被內聯到調用位置。

這對于如下方式初始化的字面常量有效：

private static final boolean MY_VALUE = false;

但對于如下方式初始化的運行時常量無效：

private static final boolean MY_VALUE = System.getProperty("dsasdkdfskdsdfk") != null;

為什么會不一樣呢？因為第一種方式字面量(literal, 硬編碼在代碼里的值，可以是布爾值、數值、字符串等等)是編譯時就能確定的，而第二種方式的值是某個調用的返回值，直到運行的那一刻才確定。

具體的常量優化規則可參考語言規范：http://docs.oracle.com/javase...

然后我就發現一個危險現象：引用自另一個jar的常量也會被內聯！

如果你引用一個第三方庫中的常量，然后升級了這個庫的版本，新版本改變了常量的值，那么你的程序就錯了！除非你重新編譯你的程序！

有時候這是很隱蔽的！例如你引用的是Tomcat的一個常量，然后你直接把程序放在新版本的Tomcat中運行！

服務器上的問題是：用反射強行修改static final變量的值，用反射能取得修改后的值，然而Java調用直接取得的值卻仍是舊值。

可用如下Test.java MyEnv.java兩個文件來重現，但是在開發環境并沒有重現出問題：

Test.java

import java.lang.reflect.Field;
import java.lang.reflect.Modifier;

public class Test {
  public static void main(String[] args) throws NoSuchFieldException, IllegalAccessException {
    Field myField = MyEnv.class.getDeclaredField("MY_VALUE");
    myField.setAccessible(true);
    
    Field modifiersField = Field.class.getDeclaredField("modifiers");
    modifiersField.setAccessible(true);
    modifiersField.setInt(myField, myField.getModifiers() & ~Modifier.FINAL);
    
    myField.set(null, true);

    System.out.println("Get via reflection: " + myField.get(null)); // true on the server
    System.out.println("Get directly:" + MyEnv.getValue()); // false on the server
  }
}

MyEnv.java

public class MyEnv {
 private static final boolean MY_VALUE = System.getProperty("dsasdkdfskdsdfk") != null;
 
 public static boolean getValue() {
 return MY_VALUE;
 }
}

按照語言規范里的編譯器常量優化規則，這個常量不會被內聯，所以開發環境的執行結果(兩個都是true)似乎是對的？

但是JVM有運行時優化——當代碼頻繁執行時，會觸發JIT編譯！

我們修改Test.java如下，執行了10萬次直接取值：

Test.java

import java.lang.reflect.Field;
import java.lang.reflect.Modifier;

public class Test {
  public static void main(String[] args) throws NoSuchFieldException, IllegalAccessException {
    for (int i = 0; i < 100000; i++) {
      MyEnv.getValue();
    }
    Field myField = MyEnv.class.getDeclaredField("MY_VALUE");
    myField.setAccessible(true);
 
    Field modifiersField = Field.class.getDeclaredField("modifiers");
    modifiersField.setAccessible(true);
    modifiersField.setInt(myField, myField.getModifiers() & ~Modifier.FINAL);
 
    myField.set(null, true);

    System.out.println("Get via reflection: " + myField.get(null)); // true on the server
    System.out.println("Get directly:" + MyEnv.getValue()); // false on the server
  }
}

現在的執行結果是true, false，重現了服務器的問題。原因是JVM在運行時通過JIT編譯再次內聯了常量。

在我的電腦上，觸發這個JIT編譯的閾值是15239，遠小于10萬。（這個閾值隨時會變，只是測著玩的）

JIT編譯是可以取消的，現在修改Test.java如下，在用反射設值后，再次執行10萬次直接取值：

public class Test {
  public static void main(String[] args) throws NoSuchFieldException, IllegalAccessException {
    for (int i = 0; i < 100000; i++) {
      MyEnv.getValue();
    }
    Field myField = MyEnv.class.getDeclaredField("MY_VALUE");
    myField.setAccessible(true);
 
    Field modifiersField = Field.class.getDeclaredField("modifiers");
    modifiersField.setAccessible(true);
    modifiersField.setInt(myField, myField.getModifiers() & ~Modifier.FINAL);
 
    myField.set(null, true);
    for (int i = 0; i < 100000; i++) {
      MyEnv.getValue();
    }
   System.out.println("Get via reflection: " + myField.get(null)); // true on the server
   System.out.println("Get directly:" + MyEnv.getValue()); // false on the server
  }
}

現在的執行結果又是true, true了。
與其說是取消了JIT，不如說是觸發了新一次JIT！可以用代碼驗證這一推測，這個就留作思考題了:)
(注意，要想觸發新的JIT，需要更大量的執行次數。)

結論：不要修改final變量，會出問題的！

關于編譯期優化的更多知識 https://briangordon.github.io...