轉載自 http://my.oschina.net/xianggao/blog/84179
作者:老妖
Java常量池技術
java中的常量池技術,是為了方便快捷地建立某些對象而出現的,當需要一個對象時,就可以從池中取一個出來(如果池中沒有則建立一個),則在需要重複建立相等變數時節省了很多時間。常量池其實也就是一個記憶體空間,不同於使用new關鍵字建立的對象所在的堆空間。 String類也是java中用得多的類,同樣為了建立String對象的方便,也實現了常量池的技術。
在本文描述常量池之前,先來瞭解一下JVM運行時資料區的記憶體模型。《深入JAVA虛擬機器》書中是這樣描述的:JVM運行時資料區的記憶體模型由五部分組成:
【1】方法區
【2】堆
【3】JAVA棧
【4】PC寄存器
【5】本地方法棧
對於String s = "haha" ,它的虛擬機器指令:
0: ldc #16; //String haha
2: astore_1
3: return
對於上面虛擬機器指令,其各自的指令流程在《深入JAVA虛擬機器》這樣描述到(結合上面執行個體):
ldc指令格式:ldc,index
ldc指令過程:要執行ldc指令,JVM首先尋找index所指定的常量池入口,在index指向的常量池入口,JVM將會尋找CONSTANT_Integer_info,CONSTANT_Float_info和CONSTANT_String_info入口。如果還沒有這些入口,JVM會解析它們。而對於上面的hahaJVM會找到CONSTANT_String_info入口,同時,將把指向被拘留String對象(由解析該入口的進程產生)的引用壓入運算元棧。
astore_1指令格式:astore_1
astore_1指令過程:要執行astore_1指令,JVM從運算元棧頂部彈出一個參考型別或者returnAddress類型值,然後將該值存入由索引1指定的局部變數中,即將參考型別或者returnAddress類型值存入局部變數1。
return 指令的過程:從方法中返回,傳回值為void。
談一下我個人理解:
從上面的ldc指令的執行過程可以得出:s的值是來自被拘留String對象(由解析該入口的進程產生)的引用,即可以理解為是從被拘留String對象的引用複製而來的,故我個人的理解是s的值是存在棧當中。上面是對於s值得分析,接著是對於"haha"值的分析,我們知道,對於String s = "haha" 其中"haha"值在JAVA程式編譯期就確定下來了的。簡單一點說,就是haha的值在程式編譯成class檔案後,就在class檔案中產生了(大家可以用UE編輯器或其它文本編輯工具在開啟class檔案後的位元組碼檔案中看到這個haha值)。執行JAVA程式的過程中,第一步是class檔案產生,然後被JVM裝載到記憶體執行。那麼JVM裝載這個class到記憶體中,其中的haha這個值,在記憶體中是怎麼為其開闢空間並儲存在哪個地區中呢?
說到這裡,我們不妨先來瞭解一下JVM常量池這個結構,《深入JAVA虛擬機器》書中有這樣的描述:
常量池
虛擬機器必須為每個被裝載的類型維護一個常量池。常量池就是該類型所用到常量的一個有序集和,包括直接常量(string,integer和floating point常量)和對其他類型,欄位和方法的符號引用。對於String常量,它的值是在常量池中的。而JVM中的常量池在記憶體當中是以表的形式存在的,對於String類型,有一張固定長度的CONSTANT_String_info表用來儲存文字字串值,注意:該表只儲存文字字串值,不儲存符號引用。說到這裡,對常量池中的字串值的儲存位置應該有一個比較明了的理解了。
具體結構
在Java程式中,有很多的東西是永恒的,不會在運行過程中變化。比如一個類的名字,一個類欄位的名字/所屬類型,一個類方法的名字/傳回型別/參數名與所屬類型,一個常量,還有在程式中出現的大量的字面值。 每一個都是常量池中的一個常量表(常量項)。而這些常量表之間又有不同,class檔案共有11種常量表,如下所示:
(1) CONSTANT_Utf8 用UTF-8編碼方式來表示程式中所有的重要常量字串。這些字串包括: ①類或介面的全限定名, ②超類的全限定名,③父介面的全限定名, ④類欄位名和所屬類型名,⑤類方法名和傳回型別名、以及參數名和所屬類型名。⑥字串字面值
表格式: tag(標誌1:佔1byte) length(字串所佔位元組的長度,佔2byte) bytes(字串位元組序列)
(2) CONSTANT_Integer、 CONSTANT_Float、 CONSTANT_Long、 CONSTANT_Double 所有基礎資料型別 (Elementary Data Type)的字面值。比如在程式中出現的1用CONSTANT_Integer表示。3.1415926F用 CONSTANT_Float表示。
表格式: tag bytes(基礎資料型別 (Elementary Data Type)所需使用的位元組序列)
(3) CONSTANT_Class 使用符號引用來表示類或介面。我們知道所有類名都以 CONSTANT_Utf8表的形式儲存。但是我們並不知道 CONSTANT_Utf8表中哪些字串是類名,那些是方法名。因此我們必須用一個指向類名字串的符號引用常量來表明。
表格式: tag name_index(給出表示類或介面名的CONSTANT_Utf8表的索引)
(4) CONSTANT_String 同 CONSTANT_Class,指向包含字串字面值的 CONSTANT_Utf8表。
表格式: tag string_index(給出表示字串字面值的CONSTANT_Utf8表的索引)
(5) CONSTANT_Fieldref 、 CONSTANT_Methodref、 CONSTANT_InterfaceMethodref 指向包含該欄位或方法所屬類名的 CONSTANT_Utf8表,以及指向包含該欄位或方法的名字和描述符的 CONSTANT_NameAndType 表
表格式: tag class _index(給出包含所屬類名的CONSTANT_Utf8表的索引) name_and_type_index(包含欄位名或方法名以及描述符的 CONSTANT_NameAndType表 的索引)
(6) CONSTANT_NameAndType 指向包含欄位名或方法名以及描述符的 CONSTANT_Utf8表。
表格式: tag name_index(給出表示欄位名或方法名的CONSTANT_Utf8表的索引) type_index(給出表示描述符的CONSTANT_Utf8表的索引)
在Java原始碼中的每一個字面值字串,都會在編譯成class檔案階段,形成標誌號為8(CONSTANT_String_info)的常量表 。當JVM載入 class檔案的時候,會為對應的常量池建立一個記憶體資料結構,並存放在方法區中。同時JVM會自動為CONSTANT_String_info常量表中的字串常量的字面值在堆中建立新的String對象(intern字串對象 ,又叫拘留字串對象)。然後把CONSTANT_String_info常量表的入口地址轉變成這個堆中String對象的直接地址(常量池解析)。
拘留字串對象
原始碼中所有相同字面值的字串常量只可能建立唯一 一個拘留字串對象。 實際上JVM是通過一個記錄了拘留字串引用的內部資料結構來維持這一特性的。在Java程式中,可以調用String的intern()方法來使得一個常規字串對象成為拘留字串對象。
八種基本類型的封裝類和對象池
Java中基本類型的封裝類的大部分都實現了常量池技術,這些類是Byte,Short,Integer,Long,Character,Boolean,另外兩種浮點數類型的封裝類則沒有實現。另外Byte,Short,Integer,Long,Character這5種整型的封裝類也只是在對應值小於等於127時才可使用對象池,也即對象不負責建立和管理大於127的這些類的對象。一些對應的測試代碼:
public class Test{
public static void main(String[] args){
//5種整形的封裝類Byte,Short,Integer,Long,Character的對象,
//在值小於127時可以使用常量池
Integer i1=127;
Integer i2=127;
System.out.println(i1==i2); //輸出true
//值大於127時,不會從常量池中取對象
Integer i3=128;
Integer i4=128;
System.out.println(i3==i4); //輸出false
//Boolean類也實現了常量池技術
Boolean bool1=true;
Boolean bool2=true;
System.out.println(bool1==bool2); //輸出true
//浮點類型的封裝類沒有實現常量池技術
Double d1=1.0;
Double d2=1.0;
System.out.println(d1==d2); //輸出false
}
}
對Integer對象的代碼補充
public static Integer valueOf(int i) {
final int offset = 128;
if (i >= -128 && i <= 127) {
return IntegerCache.cache[i + offset];
}
return new Integer(i);
}
當你直接給一個Integer對象一個int值的時候,其實它調用了valueOf方法,然後你賦的這個值很特別,是128,那麼沒有進行cache方法,相當於new了兩個新對象。所以問題中定義a、b的兩句代碼就類似於:
Integer a = new Integer(128);
Integer b = new Integer(128);
這個時候再問你,輸出結果是什嗎?你就知道是false了。如果把這個數換成127,再執行:
Integer a = 127;
Integer b = 127;
System.out.println(a == b);
結果就是:true
進行對象比較時最好還是使用equals,便於按照自己的目的進行控制。這裡引出equals()和==,equals比較的是字串字面值即比較內容,==比較引用。
看一下IntegerCache這個類裡面的內容:
private static class IntegerCache {
private IntegerCache() {
}
static final Integer cache[] = new Integer[-(-128) + 127 + 1];
static {
for (int i = 0; i < cache.length; i++)
cache[i] = new Integer(i - 128);
}
}
由於cache[]在IntegerCache類中是靜態數組,也就是只需要初始化一次,即static{......}部分,所以,如果Integer對象初始化時是-128~127的範圍,就不需要再重新定義申請空間,都是同一個對象---在IntegerCache.cache中,這樣可以在一定程度上提高效率。
針對String方面的補充
在同包同類下,引用自同一String對象.
在同包不同類下,引用自同一String對象.
在不同包不同類下,依然引用自同一String對象.
在編譯成.class時能夠識別為同一字串的,自動最佳化成常量,所以也引用自同一String對象.
在運行時建立的字串具有獨立的記憶體位址,所以不引用自同一String對象.
String的intern()方法會尋找在常量池中是否存在一份equal相等的字串,
如果有則返回一個引用,沒有則添加自己的字串進入常量池,注意:只是字串部分。 所以這時會存在2份拷貝,常量池的部分被String類私人並管理,自己的那份按對象生命週期繼續使用。
String s = "haha"
在介紹完JVM常量池的相關概念後,接著談開始提到的"haha"的值的記憶體分布的位置。對於haha的值,實際上是在class檔案被JVM裝載到記憶體當中並被引擎在解析ldc指令並執行ldc指令之前,JVM就已經為haha這個字串在常量池的CONSTANT_String_info表中分配了空間來儲存haha這個值。既然haha這個字串常量儲存在常量池中,根據《深入JAVA虛擬機器》書中描述:常量池是屬於類型資訊的一部分,類型資訊也就是每一個被轉載的類型,這個類型反映到JVM記憶體模型中是對應存在於JVM記憶體模型的方法區中,也就是這個類型資訊中的常量池概念是存在於在方法區中,而方法區是在JVM記憶體模型中的堆中由JVM來分配的。所以,haha的值是應該是存在堆空間中的。
而對於String s = new String("haha") ,它的JVM指令:
0: new #16; //class String
3: dup
4: ldc #18; //String haha
6: invokespecial #20; //Method java/lang/String."":(Ljava/lang/String;)V
9: astore_1
10: return
對於上面虛擬機器指令,其各自的指令流程在《深入JAVA虛擬機器》這樣描述到(結合上面執行個體):
new指令格式:new indexbyte1,indexbyte2
new指令過程:
要執行new指令,Jvm通過計算(indextype1<<8)|indextype2產生一個指向常量池的無符號16位索引。然後JVM根據計算出的索引尋找常量池入口。該索引所指向的常量池入口必須為CONSTANT_Class_info。如果該入口尚不存在,那麼JVM將解析這個常量池入口,該入口類型必須是類。JVM從堆中為新對象映像分配足夠大的空間,並將對象的執行個體變數設為預設值。最後JVM將指向新對象的引用objectref壓入運算元棧。
dup指令格式:dup
dup指令過程:
要執行dup指令,JVM複製了運算元棧頂部一個字長的內容,然後再將複製內容壓入棧。本指令能夠從運算元棧頂部複製任何單位字長的值。但絕對不要使用它來複製運算元棧頂部任何兩個字長(long型或double型)中的一個字長。上面例中,即複製引用objectref,這時在運算元棧存在2個引用。
ldc指令格式:ldc,index
ldc指令過程:
要執行ldc指令,JVM首先尋找index所指定的常量池入口,在index指向的常量池入口,JVM將會尋找CONSTANT_Integer_info,CONSTANT_Float_info和CONSTANT_String_info入口。如果還沒有這些入口,JVM會解析它們。而對於上面的haha,JVM會找到CONSTANT_String_info入口,同時,將把指向被拘留String對象(由解析該入口的進程產生)的引用壓入運算元棧。
invokespecial指令格式:invokespecial,indextype1,indextype2
invokespecial指令過程:對於該類而言,該指令是用來進行執行個體初始化方法的調用。鑒於該指令篇幅,具體可以查閱《深入JAVA虛擬機器》中描述。上面例子中,即通過其中一個引用調用String類的構造器,初始化對象執行個體,讓另一個相同的引用指向這個被初始化的對象執行個體,然後前一個引用彈出運算元棧。
astore_1指令格式:astore_1
astore_1指令過程:
要執行astore_1指令,JVM從運算元棧頂部彈出一個參考型別或者returnAddress類型值,然後將該值存入由索引1指定的局部變數中,即將參考型別或者returnAddress類型值存入局部變數1。
return 指令的過程:
從方法中返回,傳回值為void。
要執行astore_1指令,JVM從運算元棧頂部彈出一個參考型別或者returnAddress類型值,然後將該值存入由索引1指定的局部變數中,即將參考型別或者returnAddress類型值存入局部變數1。
通過上面6個指令,可以看出,String s = new String("haha");中的haha儲存在堆空間中,而s則是在運算元棧中。
上面是對s和haha值的記憶體情況的分析和理解;那對於String s = new String("haha");語句,到底建立了幾個對象呢?
我的理解:這裡"haha"本身就是常量池中的一個對象,而在運行時執行new String()時,將常量池中的對象複製一份放到堆中,並且把堆中的這個對象的引用交給s持有。所以這條語句就建立了2個String對象。如所示:
String相關的常見問題
String中的final用法和理解:
final StringBuffer a = new StringBuffer("111");
final StringBuffer b = new StringBuffer("222");
a=b;//此句編譯不通過
final StringBuffer a = new StringBuffer("111");
a.append("222");//編譯通過
可見,final只對引用的"值"(即記憶體位址)有效,它迫使引用只能指向初始指向的那個對象,改變它的指向會導致編譯期錯誤。至於它所指向的對象的變化,final是不負責的。
String 常量池問題的幾個例子:
[1]
String a = "a1";
String b = "a" + 1;
System.out.println((a == b)); //result = true
String a = "atrue";
String b = "a" + "true";
System.out.println((a == b)); //result = true
String a = "a3.4";
String b = "a" + 3.4;
System.out.println((a == b)); //result = true
分析:JVM對於字串常量的"+"號串連,將程式編譯期,JVM就將常量字串的"+"串連最佳化為串連後的值,拿"a" + 1來說,經編譯器最佳化後在class中就已經是a1。在編譯期其字串常量的值就確定下來,故上面程式最終的結果都為true。
[2]
String a = "ab";
String bb = "b";
String b = "a" + bb;
System.out.println((a == b)); //result = false
分析:JVM對於字串引用,由於在字串的"+"串連中,有字串引用存在,而引用的值在程式編譯期是無法確定的,即"a" + bb無法被編譯器最佳化,只有在程式運行期來動態分配並將串連後的新地址賦給b。所以上面程式的結果也就為false。
[3]
String a = "ab";
final String bb = "b";
String b = "a" + bb;
System.out.println((a == b)); //result = true
分析:和[3]中唯一不同的是bb字串加了final修飾,對於final修飾的變數,它在編譯時間被解析為常量值的一個本地拷貝儲存到自己的常量池中或嵌入到它的位元組碼流中。所以此時的"a" + bb和"a" + "b"效果是一樣的。故上面程式的結果為true。
[4]
String a = "ab";
final String bb = getBB();
String b = "a" + bb;
System.out.println((a == b)); //result = false
private static String getBB() {
return "b";
}
分析:JVM對於字串引用bb,它的值在編譯期無法確定,只有在程式運行期調用方法後,將方法的傳回值和"a"來動態串連並分配地址為b,故上面程式的結果為false。
通過上面4個例子可以得出得知:
String s = "a" + "b" + "c";
就等價於String s = "abc";
String a = "a";
String b = "b";
String c = "c";
String s = a + b + c;
這個就不一樣了,最終結果等於:
StringBuffer temp = new StringBuffer();
temp.append(a).append(b).append(c);
String s = temp.toString();
由上面的分析結果,可就不難推斷出String 採用串連運算子(+)效率低下原因分析,形如這樣的代碼:
public class Test {
public static void main(String args[]) {
String s = null;
for(int i = 0; i < 100; i++) {
s += "a";
}
}
}
每做一次 + 就產生個StringBuilder對象,然後append後就扔掉。下次迴圈再到達時重新產生個StringBuilder對象,然後 append 字串,如此迴圈直至結束。 如果我們直接採用 StringBuilder 對象進行 append 的話,我們可以節省 N - 1 次建立和銷毀對象的時間。所以對於在迴圈中要進行字串連線應用程式,一般都是用StringBuffer或StringBulider對象來進行append操作。
String對象的intern方法理解和分析:
public class Test4 {
private static String a = "ab";
public static void main(String[] args){
String s1 = "a";
String s2 = "b";
String s = s1 + s2;
System.out.println(s == a);//false
System.out.println(s.intern() == a);//true
}
}
這裡用到Java裡面是一個常量池的問題。對於s1+s2操作,其實是在堆裡面重新建立了一個新的對象,s儲存的是這個新對象在堆空間的的內容,所以s與a的值是不相等的。而當調用s.intern()方法,卻可以返回s在常量池中的地址值,因為a的值儲存在常量池中,故s.intern和a的值相等。