C#之int挑戰JAVA之Integer

本文涉及到一些JVM原理和JAVA的位元組碼指令，推薦感興趣的讀者閱讀一本有關JVM的經典書籍《深入JAVA虛擬機器(第2版)》，將它與我在《.NET 4.0物件導向程式設計漫談》仲介紹的CLR原理與IL彙編指令作個對比， 相信讀者會有一定的啟發。 而仔細對比兩個類似事物的異同，是很有效的學習方法之一。

今後我還將在個人博客上放出其他的文章，希望能説明書的讀者開拓視野，啟發思考，大家一起探討技術的奧秘。

本文所述之內容僅代表個人之理解，任何疏漏及錯誤請直接回貼指出。

1 奇特的程式輸出

前段時間，一個學生給我看了一段「非常詭異」的JAVA代碼：

public class TestInteger {


public static void main(String[] args){


Integer v1=100;


Integer v2=100;


System.out.println(v1==v2); 輸出：true


Integer w1=200;


Integer w2=200;


System.out.println(w1==w2); 輸出：false


}


}

讓這個學生最困惑的是，為什麼這些如此相似的代碼會有這樣令人意外的輸出?

我平時多使用C#，JAVA用得不多，初看到這段代碼的輸出，我也同樣非常奇怪：怎麼會這樣呢?100和200這兩個整型數值對Integer這個類有本質上的差別嗎?

為了弄明白出現上述現象的底層原因，我使用javap工具反彙編了JAVA編譯器生成的.class檔：

通過仔細閱讀JAVA編譯器生的位元組碼，我發現以下給Integer變數賦值的語句：

Integer v1=100;

實際上調用的是Integer.valueOf方法。

而完成兩個Integer變數比較的以下語句：

System.Console.WriteLine(v1 == v2);

實際生成的是if_acmpne指令。 其中的a代表「address」，cmp代表「Compare」，ne代表「not equal」。

這條指令的含義是：比較JAVA方法棧中的兩個運算元(即v1與v2)，看看它們是不是指向堆中的同一個物件。

當給v1和v2賦值100時，它們將引用同一個Integer物件。

那為什麼當值改為200時，w1和w2就「翻臉了」，分別引用不同的Integer物件?

秘密就在於Integer.valueOf方法。 幸運的是，JAVA的類庫是開源的，所以我們可以毫不費力地看到相關的原始程式碼：

public static Integer valueOf(int i){


if(i >= -128 && i <= IntegerCache.high)


return IntegerCache.cache[i + 128];


else


return new Integer(i);


}

一切真相大白，原來Integer在內部使用了一個私有的靜態類IntegerCache，此類內部封裝了一個Integer物件的cache陣列來緩存Integer物件，其代碼如下：

private static class IntegerCache {


static final Integer cache[];


//......


}

再仔細看看IntegerCache內部的代碼，會看到它使用靜態初始化塊在cache陣列中保存了[-128,127]區間內的一共256個Integer物件。

當給Integer變數直接賦整數值時，如果這個數值位於[-128,127]內，JVM(JAVA Virtual Machine)就直接使用cache中緩存的Integer物件，否則，JVM會重新創建一個Integer物件。

一切真相大白。