為什么 StringBuilder 不是線程安全的？

引言

你是不是遇到過這種問題：

?

面試官：StringBuilder 和 StringBuffer 的區(qū)別在哪？

我：StringBuilder 不是線程安全的，StringBuffer 是線程安全的

面試官：那 StringBuilder 不安全的點在哪兒？

我：。。。（啞巴了）

?

在這之前我只記住了 StringBuilder 不是線程安全的，StringBuffer 是線程安全的這個結(jié)論，至于 StringBuilder 為什么不安全從來沒有去想過。

分析

在分析設(shè)個問題之前我們要知道 StringBuilder 和 StringBuffer 的內(nèi)部實現(xiàn)跟 String 類一樣，都是通過一個 char 數(shù)組存儲字符串的，不同的是 String 類里面的 char 數(shù)組是 final 修飾的，是不可變的，而 StringBuilder 和 StringBuffer 的 char 數(shù)組是可變的。

首先通過一段代碼去看一下多線程操作 StringBuilder 對象會出現(xiàn)什么問題

public class StringBuilderDemo {

    public static void main(String[] args) throws InterruptedException {
    StringBuilder stringBuilder = new StringBuilder();
    for (int i = 0; i < 10; i++){
        new Thread(new Runnable() {
            @Override
            public void run() {
                for (int j = 0; j < 1000; j++){
                    stringBuilder.append("a");
                }
            }
        }).start();
    }

    Thread.sleep(100);
    System.out.println(stringBuilder.length());
   }
 }

我們能看到這段代碼創(chuàng)建了 10 個線程，每個線程循環(huán) 1000 次往 StringBuilder 對象里面 append 字符。正常情況下代碼應(yīng)該輸出 10000，但是實際運行會輸出什么呢？

我們看到輸出了“9326”，小于預(yù)期的 10000，并且還拋出了一個 ArrayIndexOutOfBoundsException 異常（異常不是必現(xiàn)）。

1、為什么輸出值跟預(yù)期值不一樣

我們先看一下 StringBuilder 的兩個成員變量（這兩個成員變量實際上是定義在 AbstractStringBuilder 里面的，StringBuilder 和 StringBuffer 都繼承了 AbstractStringBuilder）

//存儲字符串的具體內(nèi)容
char[] value;
//已經(jīng)使用的字符數(shù)組的數(shù)量
int count;

再看 StringBuilder 的 append()方法：

@Override
public StringBuilder append(String str) {
    super.append(str);
    return this;
}

StringBuilder 的 append()方法調(diào)用的父類 AbstractStringBuilder 的 append()方法

public AbstractStringBuilder append(String str) {
    if (str == null)
        return appendNull();
    int len = str.length();
    ensureCapacityInternal(count + len);
    str.getChars(0, len, value, count);
    count += len;
    return this;
}

我們先不管代碼的第五行和第六行干了什么，直接看第七行，count += len 不是一個原子操作。假設(shè)這個時候 count 值為 10，len 值為 1，兩個線程同時執(zhí)行到了第七行，拿到的 count 值都是 10，執(zhí)行完加法運算后將結(jié)果賦值給 count，所以兩個線程執(zhí)行完后 count 值為 11，而不是 12。這就是為什么測試代碼輸出的值要比 10000 小的原因。

2、為什么會拋出 ArrayIndexOutOfBoundsException 異常。

我們看回 AbstractStringBuilder 的 append()方法源碼的第五行，ensureCapacityInternal()方法是檢查 StringBuilder 對象的原 char 數(shù)組的容量能不能盛下新的字符串，如果盛不下就調(diào)用 expandCapacity()方法對 char 數(shù)組進行擴容。

private void ensureCapacityInternal(int minimumCapacity) {
        // overflow-conscious code
    if (minimumCapacity - value.length > 0)
        expandCapacity(minimumCapacity);
}

擴容的邏輯就是 new 一個新的 char 數(shù)組，新的 char 數(shù)組的容量是原來 char 數(shù)組的兩倍再加 2，再通過 System.arryCopy()函數(shù)將原數(shù)組的內(nèi)容復(fù)制到新數(shù)組，最后將指針指向新的 char 數(shù)組。

void expandCapacity(int minimumCapacity) {
    //計算新的容量
    int newCapacity = value.length * 2 + 2;
    //中間省略了一些檢查邏輯
    ...
    value = Arrays.copyOf(value, newCapacity);
}

Arrys.copyOf()方法

public static char[] copyOf(char[] original, int newLength) {
    char[] copy = new char[newLength];
    //拷貝數(shù)組
    System.arraycopy(original, 0, copy, 0,
                         Math.min(original.length, newLength));
    return copy;
}

AbstractStringBuilder 的 append()方法源碼的第六行，是將 String 對象里面 char 數(shù)組里面的內(nèi)容拷貝到 StringBuilder 對象的 char 數(shù)組里面，代碼如下：

str.getChars(0, len, value, count);

getChars()方法

public void getChars(int srcBegin, int srcEnd, char dst[], int dstBegin) {
    //中間省略了一些檢查
    ...
    System.arraycopy(value, srcBegin, dst, dstBegin, srcEnd - srcBegin);
    }

拷貝流程見下圖

假設(shè)現(xiàn)在有兩個線程同時執(zhí)行了 StringBuilder 的 append()方法，兩個線程都執(zhí)行完了第五行的 ensureCapacityInternal()方法，此刻 count=5。

這個時候線程 1 的 cpu 時間片用完了，線程 2 繼續(xù)執(zhí)行。線程 2 執(zhí)行完整個 append()方法后 count 變成 6 了

線程 1 繼續(xù)執(zhí)行第六行的 str.getChars()方法的時候拿到的 count 值就是 6 了，執(zhí)行 char 數(shù)組拷貝的時候就會拋出 ArrayIndexOutOfBoundsException 異常。

至此，StringBuilder 為什么不安全已經(jīng)分析完了。如果我們將測試代碼的 StringBuilder 對象換成 StringBuffer 對象會輸出什么呢？

當(dāng)然是輸出 10000 啦！那么 StringBuffer 用什么手段保證線程安全的？這個問題你點進 StringBuffer 的 append()方法里面就知道了。

當(dāng)然是輸出 10000 啦！那么 StringBuffer 用什么手段保證線程安全的？這個問題你點進 StringBuffer 的 append()方法里面就知道了。