字元串,是Java中最重要的類。這句肯定的推斷不是Java之父詹姆斯·高斯林說的,而是沉默王二說的,因此你不必懷疑它的準確性。 關於字元串,有很多的面試題,但我總覺得理論知識繞來繞去沒多大意思。你比如說:String cmower = new String("沉默王二");定義了幾個對象? 我總覺得 ...
字元串,是Java中最重要的類。這句肯定的推斷不是Java之父詹姆斯·高斯林說的,而是沉默王二說的,因此你不必懷疑它的準確性。
關於字元串,有很多的面試題,但我總覺得理論知識繞來繞去沒多大意思。你比如說:String cmower = new String("沉默王二");
定義了幾個對象?
我總覺得問我這樣的問題,就好像是在拷問我:“既然你家買了冰箱,你難道不應該知道冰箱製冷的原理?”
再說,為什麼要用String cmower = new String("沉默王二");
而不是String cmower = "沉默王二";
?
我勸各位面試官不要再纏住這樣的問題不放了,切記“學以致用”。理論知識如果一直是在繞彎彎,那真的毫無價值。如果要我來做面試官,我想要問的問題是:“你平常是怎麼判斷兩個字元串相等的?是用equals()還是==?”
前言就說這麼多。接下來,我們來探討幾個實用的知識點。
01 字元串是不可變的
我們來看一下String類的定義:
public final class String
implements java.io.Serializable, Comparable<String>, CharSequence {
}
可以發現,String類是final類型的,因此不能被繼承。
如果類可以被繼承,那麼就會破壞類的不可變性機制。因為子類可以覆蓋父類的方法,並且可以改變父類的成員變數值,一旦子類以父類的形式出現時,就不能保證類是不可變的。
String類的不可變性有什麼好處呢?
1)作為HashMap的鍵。
因為字元串是不可變的,因此它在創建的時候哈希碼(hash code)就計算好了。這也就意味著每次在使用一個字元串的哈希碼的時候不用重新計算一次,這樣更加高效,很適合作為HashMap中的鍵。
2)線程安全。
同一個字元串對象可以被多個線程共用,如果訪問頻繁的話,可以省略同步和鎖等待的時間,從而提升性能。
3)字元串常量池的需要。
稍後介紹。
特別要註意的是,String類的所有方法都沒有改變字元串本身的值,都是返回了一個新的對象。
02 字元串常量池
在Java中,常用的創建字元串的方式有兩種:
String cmower = "沉默王二";
String cmowsan = new String("沉默王三");
cmower使用雙引號,cmowsan使用new關鍵字,它們有什麼區別呢?
答案如下:
String cmower = "沉默王二";
String cmower1 = "沉默王二";
System.out.println(cmower == cmower1); // 輸出true
String cmowsan = new String("沉默王三");
String cmowsan1 = new String("沉默王三");
System.out.println(cmowsan == cmowsan1); // 輸出false
雙引號創建的相同字元串使用==
判斷時結果為true,而new關鍵字創建的相同字元串使用==
判斷時結果為false。
這是為什麼呢?
String在Java中使用過於頻繁,為了避免在系統中產生大量的String對象,Java的設計者引入了“字元串常量池”的概念。
當使用雙引號創建一個字元串時,首先會檢查字元串常量池中是否有相同的字元串對象,如果有,則直接從常量池中取出對象引用;如果沒有,則新建字元串對象,並將其放入字元串常量池中,並返回對象引用。
這也就是說,"沉默王二"是放在字元串常量池中的,cmower和cmower1兩個字元串對象引用是相同的。
而new關鍵字創建的字元串對象是不涉及字元串常量池的,直接放在堆中,也就是說,雖然cmowsan和cmowsan1都叫沉默王三,但不一個人。
強烈建議:不要使用new關鍵字的形式創建字元串對象。
03 +號和StringBuilder
由於字元串是不可變的,因此字元串在進行拼接的時候會創建新的字元串對象。大家都知道,記憶體是一定的,因此對象創建多了就會影響系統性能。
StringBuilder正是為瞭解決字元串拼接產生太多中間對象的問題而提供的一個類,可以通過append()方法把字元串添加到已有序列的末尾,非常高效。
那麼有人在進行字元串拼接的時候,就會產生疑惑:“我到底是用+號還是StringBuilder?”
我們先來看這樣一段代碼:
String chenmo = "沉默";
String wanger = "王二";
System.out.println(chenmo + wanger);
這段代碼是怎麼編譯的呢?可以使用JAD(Java反編譯工具)來看一看。
String s = "\u5A0C\u5910\u7CAF";
String s1 = "\u941C\u5B29\u7C29";
System.out.println((new StringBuilder()).append(s).append(s1).toString());
你是不是看到了StringBuilder
的影子?
沒錯,使用+號進行字元串拼接的時候,Java編譯器實際是通過StringBuilder類來完成的。
難道可以使用+號來隨意拼接字元串?反正Java編譯器已經自動地為我們優化了。
但事實並非如此,來看這樣一段代碼:
String cmowers = "";
for (int i = 0; i < 9; i++) {
cmowers += "沉默王二";
}
System.out.println(cmowers);
閉上眼睛先想一想,Java編譯器會怎麼做?我們期望的結果是在迴圈外部就創建StringBuilder,Java編譯器能如我們所願嗎?
JAD反編譯後的結果如下:
String s = "";
for(int i = 0; i < 10; i++)
s = (new StringBuilder()).append(s).append("\u5A0C\u5910\u7CAF\u941C\u5B29\u7C29").toString();
System.out.println(s);
這麼看來,StringBuilder是在for迴圈內部創建的,也就是說會創建10次。天吶,這可不是我們期望的結果!我們只希望StringBuilder創建一次。
沒辦法,Java編譯器是做不到的,只能靠我們自己:
StringBuilder cmowers = new StringBuilder();
for (int i = 0; i < 9; i++) {
cmowers.append("沉默王二");
}
System.out.println(cmowers);
強烈建議:如果只是三四個字元串的拼接,儘管使用+號操作符,別想什麼性能優化(舉個例子,你離目的地只有100米,你是打算打個計程車,還是自己步行走過去?);如果遇到多於四個字元串的拼接,或者需要用到迴圈來拼接,那就選擇StringBuilder。
在我年輕的時候,我還會犯這樣一個錯誤:
StringBuilder cmowers = new StringBuilder();
for (int i = 0; i < 9; i++) {
cmowers.append("沉默王二" + "和他的讀者朋友們");
}
System.out.println(cmowers);
我去,竟然在append()方法的內部使用+號!因為這個錯誤,我差點沒被領導打死。你可要小心點。
04 關於concat()
除了使用+號和StringBuilder對字元串進行拼接,還可以使用String類的concat()
方法。
concat()方法只不過是String類的一個方法而已,為什麼我要單獨拎出來說呢?
因為之前我要在JSP頁面的EL表達式中拼接字元串,剛開始想到的是用+號操作符,但EL表達式不是Java,+號操作符是不能拼接字元串的。我當時竟然沒想起來用concat()
!
重新銘記一下:
${item.username.concat('-').concat(item.realname)}
05 關於intern()
關於字元串的性能問題,我常在一些技術文章中看到這樣的建議:“如果一個字元串使用的頻率非常高,建議使用String.intern()
將其緩存。”
但我並不建議你這麼做,因為這個方法要顯式的調用,這樣很麻煩;況且,在代碼編寫階段,怎麼可能知道哪個字元串使用頻率很高呢?
06 關於StringUtils
據我的編程經驗來看,字元串的操作往往需要用到一個工具類,那就是org.apache.commons.lang3.StringUtils
(null安全的,也就是說,StringUtils類的方法可以接受為null的字元串,但不會拋出NullPointerException)。
不過,我最常用的方法就那麼幾個:
方法 | 等價 |
---|---|
IsEmpty(String str) |
str == null || str.length == 0 |
isBlank(String str) |
str == null || str.length == 0 || str.trim().length == 0 |
join(Object[] arrey) |
把數組中的元素連接成一個字元串返回 |
推薦閱讀:
Java異常處理:給程式罩一層保險
Java集合類:我其實沒那麼簡單