對(duì)于字符串的處理，經(jīng)常需要面對(duì)這三個(gè)類的選擇問題。一開始工作時(shí)，大黃也是看著同事的代碼，保持一致性，人家用StringBuffer我也用，節(jié)省時(shí)間。業(yè)余時(shí)間粗淺的了解了三者之間的區(qū)別，今天趁著空閑，翻出源代碼，加深一下理解。
首先上定義：
- String：字符串常量
- StringBuffer：線程安全的字符串變量
- StringBuilder：非線程安全的字符串變量
那么到底啥時(shí)候用哪一個(gè)呢，原則是什么？原則當(dāng)然是正確性和效率。大部分情況下，如果沒有任何要求，其實(shí)這三兄弟是可以互相替代的，但是一旦涉及到計(jì)算和存儲(chǔ)方面的效率我們就要看看到底用什么好了。
String的優(yōu)勢(shì)和劣勢(shì)
String是個(gè)常量，這就是他的優(yōu)勢(shì)，也是他的劣勢(shì)。常量，即不可變對(duì)象，當(dāng)你的需求是一個(gè)創(chuàng)建以后很少再改變的字符串，String是首選。但是如果你的字符串需要頻繁的進(jìn)行改變，擴(kuò)容等等，次數(shù)越多，效率越慢，與后兩者比較，簡(jiǎn)直不忍直視。主要原因就是，每一次String的改變都會(huì)創(chuàng)建一個(gè)新的對(duì)象，然后指針指向這個(gè)新的對(duì)象。頻繁大量這樣做的后果就是會(huì)觸發(fā)JVM的GC，速度變慢。
StringBuffer和StringBuilder的底層實(shí)現(xiàn)
先來看看這兩個(gè)類：
public final class StringBuilder
extends AbstractStringBuilder
implements java.io.Serializable, CharSequence
public final class StringBuffer
extends AbstractStringBuilder
implements java.io.Serializable, CharSequence
看到這里炸毛了呀，這不是完全一樣嘛，同一個(gè)父類，實(shí)現(xiàn)同樣的接口,那為毛要寫兩個(gè)啊。回到最初的定義，線程安全與非線程安全，如果繼續(xù)翻看源碼，會(huì)發(fā)現(xiàn)StringBuffer絕大部分方法都用synchonized修飾，也即線程安全。多線程不在這里展開，簡(jiǎn)單說，當(dāng)你的字符串涉及到多線程，請(qǐng)用StringBuffer。
再回到效率問題，看看這兩個(gè)類是如何處理字符串的，我們找到父類AbstractStringBuilder一看究竟。
/**
* The value is used for character storage.
*/
char[] value;
/**
* The count is the number of characters used.
*/
int count;
一上來的這兩個(gè)變量告訴我們本質(zhì)上，這個(gè)類是一個(gè)char數(shù)組，而這個(gè)count也就是我們常見的length。理解了這個(gè)我們就直奔主題看字符串的操作。
字符串的拼接
public AbstractStringBuilder append(String str) {
if (str == null)
return appendNull();
int len = str.length();
ensureCapacityInternal(count + len); //關(guān)鍵一行
str.getChars(0, len, value, count); //關(guān)鍵一行
count += len;
return this;
}
append方法，將一個(gè)字符串加在原有字符串的尾端。這個(gè)方法的關(guān)鍵自然是大黃標(biāo)注的關(guān)鍵一行的位置。第二行不詳細(xì)解釋，就是通過String的getChars來添加完成字符串的拼接，再底層，就是System. arraycopy。
那之前的一行是干什么的呢？擴(kuò)容。既然使用了數(shù)組，那就要根據(jù)實(shí)際情況擴(kuò)大它的容量，這個(gè)步驟就是通過ensureCapacityInternal(count + len)來實(shí)現(xiàn)的。來看一下具體的代碼：
private void ensureCapacityInternal(int minimumCapacity) {
// overflow-conscious code
if (minimumCapacity - value.length > 0) {
value = Arrays.copyOf(value,
newCapacity(minimumCapacity));
}
}
private int newCapacity(int minCapacity) {
// overflow-conscious code
int newCapacity = (value.length << 1) + 2;
if (newCapacity - minCapacity < 0) {
newCapacity = minCapacity;
}
return (newCapacity <= 0 || MAX_ARRAY_SIZE - newCapacity < 0)
? hugeCapacity(minCapacity)
: newCapacity;
}
private int hugeCapacity(int minCapacity) {
if (Integer.MAX_VALUE - minCapacity < 0) { // overflow
throw new OutOfMemoryError();
}
return (minCapacity > MAX_ARRAY_SIZE)
? minCapacity : MAX_ARRAY_SIZE;
}
結(jié)合這三個(gè)方法來看看他們做了什么：
- 比較當(dāng)下字符串和需要拼接的字符串的長(zhǎng)度之和與當(dāng)下AbstractStringBuilder的容量，如果不夠，通過前者的值進(jìn)行擴(kuò)容(調(diào)用newCapacity)
- 通過移位符先把當(dāng)前容量*2+2,再和拼接之和比較，取大為新容量值
- 新容量值若不為負(fù)數(shù)且不超過MAX_ARRAY_SIZE，則此擴(kuò)容完成
- 若3條件不滿足，再看拼接之和是否超過Integer.MAX_VALUE，若超過，則拋OOM, 若沒有，則取拼接之和與MAX_ARRAY_SIZE之間較大的為新容量值，擴(kuò)容完成。
上面的步驟有兩個(gè)臨界點(diǎn)，MAX_ARRAY_SIZE和Integer.MAX_VALUE
再看源碼：
private static final int MAX_ARRAY_SIZE = Integer.MAX_VALUE - 8; //AbstractStringBuilder
public static final int MAX_VALUE = 0x7fffffff;// Integer, 2147483647
所以可以得出一個(gè)很有趣的結(jié)論，雖然我有MAX_ARRAY_SIZE，但是擴(kuò)容的極限是可以超過這個(gè)值的。
字符串的插入
public AbstractStringBuilder insert(int offset, String str) {
if ((offset < 0) || (offset > length()))
throw new StringIndexOutOfBoundsException(offset);
if (str == null)
str = "null";
int len = str.length();
ensureCapacityInternal(count + len);
System.arraycopy(value, offset, value, offset + len, count - offset);
str.getChars(value, offset);
count += len;
return this;
}
流程和append幾乎一樣，不再贅述。
三兄弟的再一次比較
大黃來舉個(gè)生動(dòng)的例子幫助理解這三者的交叉比較：
有一天，大黃和大黃的朋友們要完成一次集體作畫。大黃呢，畫術(shù)不精，一開始在工作臺(tái)(JVM)上反復(fù)的畫著一張又一張(創(chuàng)建很多String對(duì)象),雖然慢慢畫的不錯(cuò)了，但是不用的草稿堆的工作臺(tái)上到處都是，無奈只能停下先收拾干凈(JVM垃圾回收)。最終成稿。大黃的朋友大白是個(gè)畫家，這種事情輕而易舉，他連草稿都沒打，直接一幅畫成(創(chuàng)建一個(gè)String對(duì)象)。另外一位朋友小凡，和大黃水平差不多，可是她更聰明，拿了可涂改的筆和紙(StringBuilder), 涂涂改改，比大黃快了很多。最后大家都完成了各自的部分，準(zhǔn)備拼接起來，可是發(fā)覺拼完以后很難看，于是大家決定重畫，在同一塊畫紙上分別作畫，因?yàn)榕禄ハ嘤绊懀詻Q定一個(gè)一個(gè)排隊(duì)畫(StringBuffer)，雖然比不上大家一擁而上快，但畫作卻能保證美觀，完整。
終章
所以大部分情況下，就效率而言，StringBuilder>StringBuffer>String
<<EffectiveJava>>一書也建議我們?cè)诖笠?guī)模拼接字符串場(chǎng)景下使用StringBuilder
最后是一個(gè)有趣的相關(guān)問題，下面兩段代碼處理速度是不是一樣的？
String result = “Sophia GY is a” + “ good” + “ author”;
String S1 = “Sophia GY is a”;
String S2 = “ good”;
String S3 = “ author”;
String result = S1 +S2 + S3;
答案是不一樣的，第一個(gè)更快，因?yàn)樵贘VM中，他會(huì)被看作String result = “Sophia GY is a good author”;，而第二段代碼則是普通的拼接。關(guān)鍵就在于你的字符串是否來自于其他String對(duì)象。
Et voilà!
