Java中字符串對象創建有兩種形式，一種為字面量形式，如String str = "hello";，另一種就是使用new這種標準的構造對象的方法，如String str = new String("hello");
對于這樣的常識，不再贅述。
首先String類是final類，為什么定義成final形式呢？
簡單點說，對于如此高頻率被使用的數據類型，設計者們認為已經設計的足夠優秀了，不需要被繼承，否則胡亂繼承重寫可能會降低程序的性能。
正如標題所述，既然深入，那我們就挖下String在jvm層面的小動作。
先解釋字面量創建的形式：
當代碼中出現字面量形式創建字符串對象時，JVM首先會對這個字面量進行檢查，如果字符串常量池中存在相同內容的字符串對象的引用，則將這個引用返回，否則新的字符串對象被創建，然后將這個引用放入字符串常量池，并返回該引用。
如下所示：
|
1
|
String str1 = "hello" ; |
當我們第一次創建的時候，這里我們認為沒有內容為hello的對象存在。JVM通過字符串常量池查找不到內容為hello的字符串對象存在，那么會創建這個字符串對象，然后將剛創建的對象的引用放入到字符串常量池中,并且將引用返回給變量str1
如果接下來有這樣一段代碼
|
1
|
String str2 = "hello" ; |
同樣JVM還是要檢測這個字面量，JVM通過查找字符串常量池，發現內容為”hello”字符串對象存在，于是將已經存在的字符串對象的引用返回給變量str2。注意這里不會重新創建新的字符串對象。
驗證是否為str1和str2是否指向同一對象，我們可以通過這段代碼
|
1
|
System.out.println(str1 == str2); |
結果為true。
第二種使用new創建：
|
1
|
String str3 = new String("hello"); |
當我們使用了new來構造字符串對象的時候，不管字符串常量池中有沒有相同內容的對象的引用，新的字符串對象都會創建。因此我們使用下面代碼測試一下，
|
1
2
|
String str3 = new String("hello");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中，對象都創建在堆內存中。字符串常量池存在于堆內存中的永久代
優缺點
字符串常量池的好處就是減少相同內容字符串的創建，節省內存空間。
如果硬要說弊端的話，就是犧牲了CPU計算時間來換空間。CPU計算時間主要用于在字符串常量池中查找是否有內容相同對象的引用。不過其內部實現為HashTable，所以計算成本較低。
GC回收？
因為字符串常量池中持有了共享的字符串對象的引用，這就是說是不是會導致這些對象無法回收？
首先問題中共享的對象一般情況下都比較小。據我查證了解，在早期的版本中確實存在這樣的問題，但是隨著弱引用的引入，目前這個問題應該沒有了。
intern使用？
關于使用intern的前提就是你清楚自己確實需要使用。比如，我們這里有一份上百萬的記錄，其中記錄的某個值多次為美國加利福尼亞州，我們不想創建上百萬條這樣的字符串對象，我們可以使用intern只在內存中保留一份即可。
總有例外？
你知道下面的代碼，會創建幾個字符串對象，在字符串常量池中保存幾個引用么？
|
1
|
String test = "a" + "b" + "c"; |
答案是只創建了一個對象，在常量池中也只保存一個引用。我們使用javap反編譯看一下即可得知。
實際上在編譯期間，已經將這三個字面量合成了一個。這樣做實際上是一種優化，避免了創建多余的字符串對象，也沒有發生字符串拼接問題。
以上這篇老生常談Java String字符串(必看篇)就是小編分享給大家的全部內容了，希望能給大家一個參考，也希望大家多多支持服務器之家。
原文鏈接：http://www.cnblogs.com/xinde123/p/7339911.html
