摘要:JVM優化的目標就是:儘可能讓對象都在新生代里分配和回收,儘量別讓太多對象頻繁進入老年代,避免頻繁對老年代進行垃圾回收,同時給系統充足的記憶體大小,避免新生代頻繁的進行垃圾回收。 本文分享自華為雲社區《千萬不要在生產環境使用這個版本的JDK,這不?記憶體又溢出了!快要裂開了!(建議收藏)》,作者: ...
摘要:JVM優化的目標就是:儘可能讓對象都在新生代里分配和回收,儘量別讓太多對象頻繁進入老年代,避免頻繁對老年代進行垃圾回收,同時給系統充足的記憶體大小,避免新生代頻繁的進行垃圾回收。
本文分享自華為雲社區《千萬不要在生產環境使用這個版本的JDK,這不?記憶體又溢出了!快要裂開了!(建議收藏)》,作者:冰 河 。
小伙伴的疑問
問題確定
排查問題的整個過程相當耗時,這裡,我就直接說定位到的問題吧。後面,我會單獨寫一篇詳細的排查問題過程的文章!
在排查問題的過程中,我發現這位小伙伴使用的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優化的目標就是:儘可能讓對象都在新生代里分配和回收,儘量別讓太多對象頻繁進入老年代,避免頻繁對老年代進行垃圾回收,同時給系統充足的記憶體大小,避免新生代頻繁的進行垃圾回收。