摘要：如果在程式中建立了比較大的物件，並且我們基於這個大物件生成了一些其他的資訊，此時，一定要釋放和這個大物件的引用關係，否則，就會埋下記憶體溢位的隱患。

本文分享自華為雲社群《【高併發】你敢信？String類竟然是導致生產環境頻繁記憶體溢位的罪魁禍首！！》，作者： 冰 河 。

最近，一名小夥伴跟我說：他寫的程式在測試環境一點問題沒有，但是發到生產環境卻會頻繁出現記憶體溢位的情況，這個問題都困擾他一週多了。於是乎，週末我便開始幫他排查各種問題。

小夥伴的疑問

問題確定

在排查問題的過程中，我發現這位小夥伴使用的JDK還是1.6版本。開始，我也沒想那麼多，繼續排查他寫的程式碼，也沒找出什麼問題。但是一旦啟動生產環境的程式，沒過多久，JVM就丟擲了記憶體溢位的異常。

這就奇怪了，怎麼回事呢？

啟動程式時加上合理的JVM引數，問題依然存在。。。

沒辦法，繼續看他的程式碼吧！無意間，我發現他寫的程式碼中，大量使用了String類的substring()方法來擷取字串。於是，我便跟到JDK中的程式碼檢視傳遞進來的引數。

這無意間點進來的一次檢視，竟然找到了問題所在！！

JDK1.6中String類的坑

經過分析，竟然發現了JDK1.6中String類的一個大坑！為啥說它是個坑呢？就是因為它的substring()方法會把人坑慘！不多說了，我們先來看下JDK1.6中的String類的substring()方法。

public String substring(int
 
 bedinIndex, int endIndex){
    if(beginIndex < 0){
        throw new StringIndexOutOfBoundsException(beginIndex);
    }
    if(endIndex > count){
        throw new StringIndexOutOfBoundsException(endIndex);
    }
    if(beginIndex > endIndex){
          throw new StringIndexOutOfBoundsException(endIndex - beginIndex);
    }
    
 
return ((beginIndex == 0) && (endIndex == count)) ? this : new String(offset + beginIndex, endIndex - beginIndex, value);
}

接下來，我們來看看JDK1.6中的String類的一個構造方法，如下所示。

String(int offset, int count, char[] value){
    this.value = value;
    this.offset = offset;
    this.count = count;
}

看到，這裡，相信細心的小夥伴已經發現了問題，導致問題的罪魁禍首就是下面的一行程式碼。

this.value = value;

在JDK1.6中，使用 String 類的建構函式建立子字串的時候，並不只是簡單的拷貝所需要的物件，而是每次都會把整個value引用進來。如果原來的字串比較大，即使這個字串不再被應用，這個字串所分配的記憶體也不會被釋放。 這也是我經過長時間的分析程式碼得出的結論，確實是太坑了！！

既然問題找到了，那我們就要解決這個問題。

升級JDK

既然JDK1.6中的String類存在如此巨大的坑，那最直接有效的方式就是升級JDK。於是，我便跟小夥伴說明了情況，讓他將JDK升級到JDK1.8。

同樣的，我們也來看下JDK1.8中的String類的substring()方法。

public String substring(int beginIndex, int endIndex) {
    if (beginIndex < 0) {
        throw new StringIndexOutOfBoundsException(beginIndex);
    }
    if (endIndex > value.length) {
        throw new StringIndexOutOfBoundsException(endIndex);
    }
    int subLen = endIndex - beginIndex;
    if (subLen < 0) {
        throw new StringIndexOutOfBoundsException(subLen);
    }
    return ((beginIndex == 0) && (endIndex == value.length)) ? this
        : new String(value, beginIndex, subLen);
}

在JDK1.8中的String類的substring()方法中，也呼叫了String類的構造方法來生成子字串，我們來看看這個構造方法，如下所示。

public String(char value[], int offset, int count) {
    if (offset < 0) {
        throw new StringIndexOutOfBoundsException(offset);
    }
    if (count <= 0) {
        if (count < 0) {
            throw new StringIndexOutOfBoundsException(count);
        }
        if (offset <= value.length) {
            this.value = "".value;
            return;
        }
    }
    // Note: offset or count might be near -1>>>1.
    if (offset > value.length - count) {
        throw new StringIndexOutOfBoundsException(offset + count);
    }
    this.value = Arrays.copyOfRange(value, offset, offset+count);
}

在JDK1.8中，當我們需要一個子字串的時候，substring 生成了一個新的字串，這個字串通過建構函式的 Arrays.copyOfRange 函式進行構造。這個是沒啥問題。

優化JVM啟動引數

這裡，為了更好的提升系統的效能，我也幫這位小夥伴優化了JVM啟動引數。

經小夥伴授權， 我簡單列下他們的業務規模和伺服器配置：整套系統採用分散式架構，架構中的各業務服務採用叢集部署，日均訪問量上億，日均交易訂單50W~100W，訂單系統的各伺服器節點配置為4核8G。目前已將JDK升級到1.8版本。

根據上述條件，我給出了JVM調優後的引數配置。

-Xms3072M -Xmx3072M -Xmn2048M -Xss1M -XX:MetaspaceSize=256M -XX:MaxMetaspaceSize=256M

至於，為啥會給出上述JVM引數配置，後續我會單獨寫文章來具體分析如何根據實際業務場景來進行JVM引數調優。

經過分析和解決問題，小夥伴的程式在生產環境下執行的很平穩，至少目前還未出現記憶體溢位的情況！！

結論

如果在程式中建立了比較大的物件，並且我們基於這個大物件生成了一些其他的資訊，此時，一定要釋放和這個大物件的引用關係，否則，就會埋下記憶體溢位的隱患。

JVM優化的目標就是：儘可能讓物件都在新生代裡分配和回收，儘量別讓太多物件頻繁進入老年代，避免頻繁對老年代進行垃圾回收，同時給系統充足的記憶體大小，避免新生代頻繁的進行垃圾回收。

點選關注，第一時間瞭解華為雲新鮮技術~