Java中的字符串常量池

Java中的字符串常量池

Java中字符串對象建立有兩種形式,一種爲字面量形式,如String str = "droid";,另外一種就是使用new這種標準的構造對象的方法,如String str = new String("droid");,這兩種方式咱們在代碼編寫時都常用,尤爲是字面量的方式。然而這兩種實現其實存在着一些性能和內存佔用的差異。這一切都是源於JVM爲了減小字符串對象的重複建立,其維護了一個特殊的內存,這段內存被成爲字符串常量池或者字符串字面量池。html

工做原理

當代碼中出現字面量形式建立字符串對象時,JVM首先會對這個字面量進行檢查,若是字符串常量池中存在相同內容的字符串對象的引用,則將這個引用返回,不然新的字符串對象被建立,而後將這個引用放入字符串常量池,並返回該引用。java

舉例說明

字面量建立形式

1
String str1 = "droid"; 

JVM檢測這個字面量,這裏咱們認爲沒有內容爲droid的對象存在。JVM經過字符串常量池查找不到內容爲droid的字符串對象存在,那麼會建立這個字符串對象,而後將剛建立的對象的引用放入到字符串常量池中,而且將引用返回給變量str1。android

若是接下來有這樣一段代碼安全

1
String str2 = "droid"; 

一樣JVM仍是要檢測這個字面量,JVM經過查找字符串常量池,發現內容爲」droid」字符串對象存在,因而將已經存在的字符串對象的引用返回給變量str2。注意這裏不會從新建立新的字符串對象。bash

驗證是否爲str1和str2是否指向同一對象,咱們能夠經過這段代碼app

1
System.out.println(str1 == str2); 

結果爲trueide

使用new建立

1
String str3 = new String("droid"); 

當咱們使用了new來構造字符串對象的時候,無論字符串常量池中有沒有相同內容的對象的引用,新的字符串對象都會建立。所以咱們使用下面代碼測試一下,性能

1
2 
String str3 = new String("droid"); System.out.println(str1 == str3); 

結果如咱們所想,爲false,代表這兩個變量指向的爲不一樣的對象。測試

intern

對於上面使用new建立的字符串對象,若是想將這個對象的引用加入到字符串常量池,可使用intern方法。優化

調用intern後,首先檢查字符串常量池中是否有該對象的引用,若是存在,則將這個引用返回給變量,不然將引用加入並返回給變量。

1
2 
String str4 = str3.intern(); System.out.println(str4 == str1); 

輸出的結果爲true

疑難問題

前提條件?

字符串常量池實現的前提條件就是Java中String對象是不可變的,這樣能夠安全保證多個變量共享同一個對象。若是Java中的String對象可變的話,一個引用操做改變了對象的值,那麼其餘的變量也會受到影響,顯然這樣是不合理的。

引用 or 對象

字符串常量池中存放的時引用仍是對象,這個問題是最多見的。字符串常量池存放的是對象引用,不是對象。在Java中,對象都建立在堆內存中

更新驗證,收到的不少評論也在討論這個問題,我簡單的進行了驗證。 驗證環境

1
2 3 4 5 6 7 8 9 10 11 12 13 
22:18:54-androidyue~/Videos$ cat /etc/os-release NAME=Fedora VERSION="17 (Beefy Miracle)" ID=fedora VERSION_ID=17 PRETTY_NAME="Fedora 17 (Beefy Miracle)" ANSI_COLOR="0;34" CPE_NAME="cpe:/o:fedoraproject:fedora:17"  22:19:04-androidyue~/Videos$ java -version java version "1.7.0_25" OpenJDK Runtime Environment (fedora-2.3.12.1.fc17-x86_64) OpenJDK 64-Bit Server VM (build 23.7-b01, mixed mode) 

驗證思路:如下的Java程序讀取一個大小爲82M的視頻文件,以字符串形式進行intern操做。

1
2 
22:01:17-androidyue~/Videos$ ll -lh | grep why_to_learn.mp4 -rw-rw-r--. 1 androidyue androidyue 82M Oct 20 2013 why_to_learn.mp4 

驗證代碼

1
2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 
import java.io.BufferedReader; import java.io.FileNotFoundException; import java.io.FileReader; import java.io.IOException;   public class TestMain {  private static String fileContent;  public static void main(String[] args) {  fileContent = readFileToString(args[0]);  if (null != fileContent) {  fileContent = fileContent.intern();  System.out.println("Not Null");  }  }    private static String readFileToString(String file) {  BufferedReader reader = null;  try {  reader = new BufferedReader(new FileReader(file));  StringBuffer buff = new StringBuffer();  String line;  while ((line = reader.readLine()) != null) {  buff.append(line);  }  return buff.toString();  } catch (FileNotFoundException e) {  e.printStackTrace();  } catch (IOException e) {  e.printStackTrace();  } finally {  if (null != reader) {  try {  reader.close();  } catch (IOException e) {  e.printStackTrace();  }  }  }  return null;  } } 

因爲字符串常量池存在於堆內存中的永久代,適用於Java8以前。咱們經過設置永久代一個很小的值來進行驗證。若是字符串對象存在字符串常量池中,那麼必然拋出java.lang.OutOfMemoryError permgen space錯誤。

1
java -XX:PermSize=6m TestMain ~/Videos/why_to_learn.mp4 

運行證實程序沒有拋出OOM,其實這個不能很好的證實存儲的是對象仍是引用。

可是這個至少證實了字符串的實際內容對象char[]不存放在字符串常量池中。既然這樣的話,其實字符串常量池存儲字符串對象仍是字符串對象的引用反而不是那麼重要。但我的仍是傾向於存儲的爲引用。

優缺點

字符串常量池的好處就是減小相同內容字符串的建立,節省內存空間。

若是硬要說弊端的話,就是犧牲了CPU計算時間來換空間。CPU計算時間主要用於在字符串常量池中查找是否有內容相同對象的引用。不過其內部實現爲HashTable,因此計算成本較低。

GC回收?

由於字符串常量池中持有了共享的字符串對象的引用,這就是說是否是會致使這些對象沒法回收?

首先問題中共享的對象通常狀況下都比較小。據我查證瞭解,在早期的版本中確實存在這樣的問題,可是隨着弱引用的引入,目前這個問題應該沒有了。

關於這個問題,能夠具體瞭解這片文章interned Strings : Java Glossary

intern使用?

關於使用intern的前提就是你清楚本身確實須要使用。好比,咱們這裏有一份上百萬的記錄,其中記錄的某個值屢次爲美國加利福尼亞州,咱們不想建立上百萬條這樣的字符串對象,咱們可使用intern只在內存中保留一份便可。關於intern更深刻的瞭解請參考深刻解析String#intern

總有例外?

你知道下面的代碼,會建立幾個字符串對象,在字符串常量池中保存幾個引用麼?

1
String test = "a" + "b" + "c"; 

答案是隻建立了一個對象,在常量池中也只保存一個引用。咱們使用javap反編譯看一下便可得知。

1
2 3 4 5 6 7 8 9 10 11 12 13 14 
17:02 $ javap -c TestInternedPoolGC Compiled from "TestInternedPoolGC.java" public class TestInternedPoolGC extends java.lang.Object{ public TestInternedPoolGC();  Code:  0: aload_0  1: invokespecial #1; //Method java/lang/Object."<init>":()V  4: return  public static void main(java.lang.String[]) throws java.lang.Exception;  Code:  0: ldc #2; //String abc  2: astore_1  3: return 

看到了麼,實際上在編譯期間,已經將這三個字面量合成了一個。這樣作其實是一種優化,避免了建立多餘的字符串對象,也沒有發生字符串拼接問題。關於字符串拼接,能夠查看Java細節:字符串的拼接

轉載自:http://droidyue.com/blog/2014/12/21/string-literal-pool-in-java/

相關文章
相關標籤/搜索