竟然還有人使用這個有Bug的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優化的目標就是：盡可能讓對象都在新生代里分配和回收，盡量別讓太多對象頻繁進入老年代，避免頻繁對老年代進行垃圾回收，同時給系統充足的內存大小，避免新生代頻繁的進行垃圾回收。
