JVM常量池及字符串==比較分析

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 全部基本數據類型的字面值。好比在程序中出現的1用CONSTANT_Integer表示。3.1415926F用 CONSTANT_Float表示。

表格式： tag bytes(基本數據類型所需使用的字節序列)

(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的值相等。