從為什么String=String談到StringBuilder和StringBuffer

前言

有這么一段代碼：

public class TestMain
{
    public static void main(String[] args)
    {
        String str0 = "123";
        String str1 = "123";
        System.out.println(str0 == str1);
    }
}

運行結果是什么？答案當然是true。對，答案的確是true，但是這是為什么呢？很多人第一反應肯定是兩個"123"的String當然相等啊，這還要想。但是"=="在Java比較的不是兩個對象的值，而是比較兩個對象的引用是否相等，和兩個String都是"123"又有什么關系呢？或者我們把程序修改一下

public class TestMain
{
    public static void main(String[] args)
    {
        String str2 = new String("234");
        String str3 = new String("234");
        System.out.println(str2 == str3);
    }
}

這時候運行結果就是false了，因為盡管兩個String對象都是"234"，但是str2和str3是兩個不同的引用，所以返回的false。OK，圍繞第一段代碼返回true，第二段代碼返回false，開始文章的內容。

 

為什么String=String？

在JVM中有一塊區域叫做常量池，關於常量池，我在寫虛擬機的時候有專門提到http://www.cnblogs.com/xrq730/p/4827590.html。常量池中的數據是那些在編譯期間被確定，並被保存在已編譯的.class文件中的一些數據。除了包含所有的8種基本數據類型（char、byte、short、int、long、float、double、boolean）外，還有String及其數組的常量值，另外還有一些以文本形式出現的符號引用。

Java棧的特點是存取速度快（比堆塊），但是空間小，數據生命周期固定，只能生存到方法結束。我們定義的boolean b = true、char c = 'c'、String str = “123”，這些語句，我們拆分為幾部分來看：

1、true、c、123，這些等號右邊的指的是編譯期間可以被確定的內容，都被維護在常量池中

2、b、c、str這些等號左邊第一個出現的指的是一個引用，引用的內容是等號右邊數據在常量池中的地址

3、boolean、char、String這些是引用的類型

棧有一個特點，就是數據共享。回到我們第一個例子，第五行String str0 = "123"，編譯的時候，在常量池中創建了一個常量"123"，然后走第六行String str1 = "123"，先去常量池中找有沒有這個"123"，發現有，str1也指向常量池中的"123"，所以第七行的str0 == str1返回的是true，因為str0和str1指向的都是常量池中的"123"這個字符串的地址。當然如果String str1 = "234"，就又不一樣了，因為常量池中沒有"234"，所以會在常量池中創建一個"234"，然后str1代表的是這個"234"的地址。分析了String，其實其他基本數據類型也都是一樣的：先看常量池中有沒有要創建的數據，有就返回數據的地址，沒有就創建一個。

第二個例子呢？Java虛擬機的解釋器每遇到一個new關鍵字，都會在堆內存中開辟一塊內存來存放一個String對象，所以str2、str3指向的堆內存中雖然存儲的是相等的"234"，但是由於是兩塊不同的堆內存，因此str2 == str3返回的仍然是false，網上找到一張圖表示一下這個概念：

 

 

為什么要使用StringBuilder和StringBuffer拼接字符串？

大家在開發中一定有一個原則是"利用StringBuilder和StringBuffer拼接字符串"，但是為什么呢？用一段代碼來分析一下：

public class StringTest {

    @Test
    public void testStringPlus() {
        String str = "111";
        str += "222";
        str += "333";
        System.out.println(str);
    }
    
}

這段代碼，我們找到編譯后的StringTest.class文件，使用"javap -verbose StringTest"或者"javap -c StringTest"都可以，反編譯一下class獲取到對應的字節碼：

  public void testStringPlus();
    Code:
       0: ldc           #17                 // String 111
       2: astore_1
       3: new           #19                 // class java/lang/StringBuilder
       6: dup
       7: aload_1
       8: invokestatic  #21                 // Method java/lang/String.valueOf:(Ljava/lang/Object;)L
java/lang/String;
      11: invokespecial #27                 // Method java/lang/StringBuilder."<init>":(Ljava/lang/S
tring;)V
      14: ldc           #30                 // String 222
      16: invokevirtual #32                 // Method java/lang/StringBuilder.append:(Ljava/lang/Str
ing;)Ljava/lang/StringBuilder;
      19: invokevirtual #36                 // Method java/lang/StringBuilder.toString:()Ljava/lang/
String;
      22: astore_1
      23: new           #19                 // class java/lang/StringBuilder
      26: dup
      27: aload_1
      28: invokestatic  #21                 // Method java/lang/String.valueOf:(Ljava/lang/Object;)L
java/lang/String;
      31: invokespecial #27                 // Method java/lang/StringBuilder."<init>":(Ljava/lang/S
tring;)V
      34: ldc           #40                 // String 333
      36: invokevirtual #32                 // Method java/lang/StringBuilder.append:(Ljava/lang/Str
ing;)Ljava/lang/StringBuilder;
      39: invokevirtual #36                 // Method java/lang/StringBuilder.toString:()Ljava/lang/
String;
      42: astore_1
      43: getstatic     #42                 // Field java/lang/System.out:Ljava/io/PrintStream;
      46: aload_1
      47: invokevirtual #48                 // Method java/io/PrintStream.println:(Ljava/lang/String
;)V
      50: return
}

這段字節碼不用看得很懂，大致上能明白就好，意思很明顯：編譯器每次碰到"+"的時候，會new一個StringBuilder出來，接着調用append方法，在調用toString方法，生成新字符串。

那么，這意味着，如果代碼中有很多的"+"，就會每個"+"生成一次StringBuilder，這種方式對內存是一種浪費，效率很不好。

在Java中還有一種拼接字符串的方式，就是String的concat方法，其實這種方式拼接字符串也不是很好，具體原因看一下concat方法的實現：

public String concat(String str) {
    int otherLen = str.length();
    if (otherLen == 0) {
        return this;
    }
    int len = value.length;
    char buf[] = Arrays.copyOf(value, len + otherLen);
    str.getChars(buf, len);
    return new String(buf, true);
}

意思就是通過兩次字符串的拷貝，產生一個新的字符數組buf[]，再根據字符數組buf[]，new一個新的String對象出來，這意味着concat方法調用N次，將發生N*2次數組拷貝以及new出N個String對象，無論對於時間還是空間都是一種浪費。

根據上面的解讀，由於"+"拼接字符串與String的concat方法拼接字符串的低效，我們才需要使用StringBuilder和StringBuffer來拼接字符串。以StringBuilder為例：

public class TestMain
{
    public static void main(String[] args)
    {
        StringBuilder sb = new StringBuilder("111");
        sb.append("222");
        sb.append("111");
        sb.append("111");
        sb.append("444");
        System.out.println(sb.toString());
    }
}

StringBuffer和StringBuilder原理一樣，無非是在底層維護了一個char數組，每次append的時候就往char數組里面放字符而已，在最終sb.toString()的時候，用一個new String()方法把char數組里面的內容都轉成String，這樣，整個過程中只產生了一個StringBuilder對象與一個String對象，非常節省空間。StringBuilder唯一的性能損耗點在於char數組不夠的時候需要進行擴容，擴容需要進行數組拷貝，一定程度上降低了效率。

StringBuffer和StringBuilder用法一模一樣，唯一的區別只是StringBuffer是線程安全的，它對所有方法都做了同步，StringBuilder是線程非安全的，所以在不涉及線程安全的場景，比如方法內部，盡量使用StringBuilder，避免同步帶來的消耗。

另外，StringBuffer和StringBuilder還有一個優化點，上面說了，擴容的時候有性能上的損耗，那么如果可以估計到要拼接的字符串的長度的話，盡量利用構造函數指定他們的長度。

 

真的不能用"+"拼接字符串？

雖然說不要用"+"拼接字符串，因為會產生大量的無用StringBuilder對象，但也不是不可以，比如可以使用以下的方式：

public class TestMain
{
    public static void main(String[] args)
    {
        String str = "111" + "222" + "333" + "444";
        System.out.println(str);
    }
}

就這種連續+的情況，實際上編譯的時候JVM會只產生一個StringBuilder並連續append等號后面的字符串。

不過上面的例子要注意一點，因為"111"、"222"、"333"、"444"都是編譯期間即可得知的常量，因為第5行的代碼JVM在編譯的時候並不會生成一個StringBuilder而是直接生成字符串"111222333444"。

但是這么寫得很少，主要原因有兩點：

1、例子比較簡單，但實際上大量的“+”會導致代碼的可讀性非常差

2、待拼接的內容可能從各種地方獲取，比如調用接口、從.properties文件中、從.xml文件中，這樣的場景下盡管用多個“+”的方式也不是不可以，但會讓代碼維護性不太好