Java 分析并解決內(nèi)存泄漏的實(shí)例
這幾天,一直在為Java的“內(nèi)存泄露”問題糾結(jié)。Java應(yīng)用程序占用的內(nèi)存在不斷的、有規(guī)律的上漲,最終超過了監(jiān)控閾值。福爾摩 斯不得不出手了!
分析內(nèi)存泄露的一般步驟
如果發(fā)現(xiàn)Java應(yīng)用程序占用的內(nèi)存出現(xiàn)了泄露的跡象,那么我們一般采用下面的步驟分析:
- 把Java應(yīng)用程序使用的heap dump下來
- 使用Java heap分析工具,找出內(nèi)存占用超出預(yù)期(一般是因?yàn)閿?shù)量太多)的嫌疑對象
- 必要時,需要分析嫌疑對象和其他對象的引用關(guān)系。
- 查看程序的源代碼,找出嫌疑對象數(shù)量過多的原因。
dump heap
如果Java應(yīng)用程序出現(xiàn)了內(nèi)存泄露,千萬別著急著把應(yīng)用殺掉,而是要保存現(xiàn)場。如果是互聯(lián)網(wǎng)應(yīng)用,可以把流量切到其他服務(wù)器。保存現(xiàn)場的目的就是為了把 運(yùn)行中JVM的heap dump下來。
JDK自帶的jmap工具,可以做這件事情。它的執(zhí)行方法是:
jmap -dump:format=b,file=heap.bin <pid>
format=b的含義是,dump出來的文件時二進(jìn)制格式。
file-heap.bin的含義是,dump出來的文件名是heap.bin。
<pid>就是JVM的進(jìn)程號。
(在linux下)先執(zhí)行ps aux | grep java,找到JVM的pid;然后再執(zhí)行jmap -dump:format=b,file=heap.bin <pid>,得到heap dump文件。
analyze heap
將二進(jìn)制的heap dump文件解析成human-readable的信息,自然是需要專業(yè)工具的幫助,這里推薦Memory Analyzer 。
Memory Analyzer,簡稱MAT,是Eclipse基金會的開源項(xiàng)目,由SAP和IBM捐助。巨頭公司出品的軟件還是很中用的,MAT可以分析包含數(shù)億級對 象的heap、快速計算每個對象占用的內(nèi)存大小、對象之間的引用關(guān)系、自動檢測內(nèi)存泄露的嫌疑對象,功能強(qiáng)大,而且界面友好易用。
MAT的界面基于Eclipse開發(fā),以兩種形式發(fā)布:Eclipse插件和Eclipe RCP。MAT的分析結(jié)果以圖片和報表的形式提供,一目了然。總之個人還是非常喜歡這個工具的。下面先貼兩張官方的screenshots:
言歸正傳,我用MAT打開了heap.bin,很容易看出,char[]的數(shù)量出其意料的多,占用90%以上的內(nèi)存 。一般來說,char[]在JVM確實(shí)會占用很多內(nèi)存,數(shù)量也非常多,因?yàn)镾tring對象以char[]作為內(nèi)部存儲。但是這次的char[]太貪婪 了,仔細(xì)一觀察,發(fā)現(xiàn)有數(shù)萬計的char[],每個都占用數(shù)百K的內(nèi)存 。這個現(xiàn)象說明,Java程序保存了數(shù)以萬計的大String對象 。結(jié)合程序的邏輯,這個是不應(yīng)該的,肯定在某個地方出了問題。
順藤摸瓜
在可疑的char[]中,任意挑了一個,使用Path To GC Root功能,找到該char[]的引用路徑,發(fā)現(xiàn)String對象是被一個HashMap中引用的 。這個也是意料中的事情,Java的內(nèi)存泄露多半是因?yàn)閷ο蟊贿z留在全局的HashMap中得不到釋放。不過,該HashMap被用作一個緩存,設(shè)置了緩 存條目的閾值,導(dǎo)達(dá)到閾值后會自動淘汰。從這個邏輯分析,應(yīng)該不會出現(xiàn)內(nèi)存泄露的。雖然緩存中的String對象已經(jīng)達(dá)到數(shù)萬計,但仍然沒有達(dá)到預(yù)先設(shè)置 的閾值(閾值設(shè)置地比較大,因?yàn)楫?dāng)時預(yù)估String對象都比較小)。
但是,另一個問題引起了我的注意:為什么緩存的String對象如此巨大?內(nèi)部char[]的長度達(dá)數(shù)百K。雖然緩存中的 String對象數(shù)量還沒有達(dá)到閾值,但是String對象大小遠(yuǎn)遠(yuǎn)超出了我們的預(yù)期,最終導(dǎo)致內(nèi)存被大量消耗,形成內(nèi)存泄露的跡象(準(zhǔn)確說應(yīng)該是內(nèi)存消 耗過多) 。
就這個問題進(jìn)一步順藤摸瓜,看看String大對象是如何被放到HashMap中的。通過查看程序的源代碼,我發(fā)現(xiàn),確實(shí)有String大對象,不 過并沒有把String大對象放到HashMap中,而是把String大對象進(jìn)行split(調(diào)用String.split方法),然后將split出 來的String小對象放到HashMap中 了。
這就奇怪了,放到HashMap中明明是split之后的String小對象,怎么會占用那么大空間呢?難道是String類的split方法有問題?
查看代碼
帶著上述疑問,我查閱了Sun JDK6中String類的代碼,主要是是split方法的實(shí)現(xiàn):
public String[] split(String regex, int limit) { return Pattern.compile(regex).split(this, limit); }
可以看出,Stirng.split方法調(diào)用了Pattern.split方法。繼續(xù)看Pattern.split方法的代碼:
public String[] split(CharSequence input, int limit) { int index = 0; boolean matchLimited = limit > 0; ArrayList<String> matchList = new ArrayList<String>(); Matcher m = matcher(input); // Add segments before each match found while(m.find()) { if (!matchLimited || matchList.size() < limit - 1) { String match = input.subSequence(index, m.start()).toString(); matchList.add(match); index = m.end(); } else if (matchList.size() == limit - 1) { // last one String match = input.subSequence(index, input.length()).toString(); matchList.add(match); index = m.end(); } } // If no match was found, return this if (index == 0) return new String[] {input.toString()}; // Add remaining segment if (!matchLimited || matchList.size() < limit) matchList.add(input.subSequence(index, input.length()).toString()); // Construct result int resultSize = matchList.size(); if (limit == 0) while (resultSize > 0 && matchList.get(resultSize-1).equals("")) resultSize--; String[] result = new String[resultSize]; return matchList.subList(0, resultSize).toArray(result); } 注意看第9行:Stirng match = input.subSequence(intdex, m.start()).toString();
這里的match就是split出來的String小對象,它其實(shí)是String大對象subSequence的結(jié)果。繼續(xù)看 String.subSequence的代碼:
public CharSequence subSequence(int beginIndex, int endIndex) { return this.substring(beginIndex, endIndex); } String.subSequence有調(diào)用了String.subString,繼續(xù)看:
public String substring(int beginIndex, 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); }
看第11、12行,我們終于看出眉目,如果subString的內(nèi)容就是完整的原字符串,那么返回原String對象;否則,就會創(chuàng)建一個新的 String對象,但是這個String對象貌似使用了原String對象的char[]。我們通過String的構(gòu)造函數(shù)確認(rèn)這一點(diǎn):
// Package private constructor which shares value array for speed. String(int offset, int count, char value[]) { this.value = value; this.offset = offset; this.count = count; }
為了避免內(nèi)存拷貝、加快速度,Sun JDK直接復(fù)用了原String對象的char[],偏移量和長度來標(biāo)識不同的字符串內(nèi)容。也就是說,subString出的來String小對象 仍然會指向原String大對象的char[],split也是同樣的情況 。這就解釋了,為什么HashMap中String對象的char[]都那么大。
原因解釋
其實(shí)上一節(jié)已經(jīng)分析出了原因,這一節(jié)再整理一下:
程序從每個請求中得到一個String大對象,該對象內(nèi)部char[]的長度達(dá)數(shù)百K。
程序?qū)tring大對象做split,將split得到的String小對象放到HashMap中,用作緩存。
Sun JDK6對String.split方法做了優(yōu)化,split出來的Stirng對象直接使用原String對象的char[]
HashMap中的每個String對象其實(shí)都指向了一個巨大的char[]
HashMap的上限是萬級的,因此被緩存的Sting對象的總大小=萬*百K=G級。
G級的內(nèi)存被緩存占用了,大量的內(nèi)存被浪費(fèi),造成內(nèi)存泄露的跡象。
解決方案
原因找到了,解決方案也就有了。split是要用的,但是我們不要把split出來的String對象直接放到HashMap中,而是調(diào)用一下 String的拷貝構(gòu)造函數(shù)String(String original),這個構(gòu)造函數(shù)是安全的,具體可以看代碼:
/** * Initializes a newly created {@code String} object so that it represents * the same sequence of characters as the argument; in other words, the * newly created string is a copy of the argument string. Unless an * explicit copy of {@code original} is needed, use of this constructor is * unnecessary since Strings are immutable. * * @param original * A {@code String} */ public String(String original) { int size = original.count; char[] originalValue = original.value; char[] v; if (originalValue.length > size) { // The array representing the String is bigger than the new // String itself. Perhaps this constructor is being called // in order to trim the baggage, so make a copy of the array. int off = original.offset; v = Arrays.copyOfRange(originalValue, off, off+size); } else { // The array representing the String is the same // size as the String, so no point in making a copy. v = originalValue; } this.offset = 0; this.count = size; this.value = v; }
只是,new String(string)的代碼很怪異,囧?;蛟S,subString和split應(yīng)該提供一個選項(xiàng),讓程序員控制是否復(fù)用String對象的 char[]。
是否Bug
雖然,subString和split的實(shí)現(xiàn)造成了現(xiàn)在的問題,但是這能否算String類的bug呢?個人覺得不好說。因?yàn)檫@樣的優(yōu)化是比較合理 的,subString和spit的結(jié)果肯定是原字符串的連續(xù)子序列。只能說,String不僅僅是一個核心類,它對于JVM來說是與原始類型同等重要的 類型。
JDK實(shí)現(xiàn)對String做各種可能的優(yōu)化都是可以理解的。但是優(yōu)化帶來了憂患,我們程序員足夠了解他們,才能用好他們。
一些補(bǔ)充
有個地方我沒有說清楚。
我的程序是一個Web程序,每次接受請求,就會創(chuàng)建一個大的String對象,然后對該String對象進(jìn)行split,最后split之后的String對象放到全局緩存中。如果接收了5W個請求,那么就會有5W個大String對象。這5W個大String對象都被存儲在全局緩存中,因此會造成內(nèi)存泄漏。我原以為緩存的是5W個小String,結(jié)果都是大String。
有同學(xué)后續(xù)建議用"java.io.StreamTokenizer"來解決本文的問題。確實(shí)是終極解決方案,比我上面提到的“new String()”,要好很多很多。
以上就是Java 分析并解決內(nèi)存泄漏的實(shí)例的詳細(xì)內(nèi)容,更多關(guān)于Java 內(nèi)存泄漏的資料請關(guān)注腳本之家其它相關(guān)文章!
- Java中的內(nèi)存泄漏
- 排查Java應(yīng)用內(nèi)存泄漏問題的步驟
- Java內(nèi)部類的實(shí)現(xiàn)原理與可能的內(nèi)存泄漏說明
- macOS上使用gperftools定位Java內(nèi)存泄漏問題及解決方案
- Java虛擬機(jī)內(nèi)存溢出與內(nèi)存泄漏
- Android性能優(yōu)化之利用Rxlifecycle解決RxJava內(nèi)存泄漏詳解
- Java中關(guān)于內(nèi)存泄漏出現(xiàn)的原因匯總及如何避免內(nèi)存泄漏(超詳細(xì)版)
- 解析Java的JNI編程中的對象引用與內(nèi)存泄漏問題
- Java基礎(chǔ)詳解之內(nèi)存泄漏
相關(guān)文章
SpringMVC自定義類型轉(zhuǎn)換器實(shí)現(xiàn)解析
這篇文章主要介紹了SpringMVC自定義類型轉(zhuǎn)換器實(shí)現(xiàn)解析,文中通過示例代碼介紹的非常詳細(xì),對大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價值,需要的朋友可以參考下2019-12-12springboot版本升級以及解決springsecurity漏洞的問題
這篇文章主要介紹了springboot版本升級以及解決springsecurity漏洞的問題,具有很好的參考價值,希望對大家有所幫助,如有錯誤或未考慮完全的地方,望不吝賜教2024-08-08Java前端開發(fā)框架實(shí)現(xiàn)的流程和代碼示例
我們可以實(shí)現(xiàn)一個Java前端開發(fā)框架,這個框架包含了初始化、組件渲染、組件更新、事件監(jiān)聽和事件觸發(fā)等功能,希望這個指南能夠?qū)側(cè)胄械男“子兴鶐椭?/div> 2023-10-10java實(shí)現(xiàn)解析Cron時間表達(dá)式為中文描述
這篇文章主要為大家詳細(xì)介紹了java如何實(shí)現(xiàn)解析Cron時間表達(dá)式為中文描述,文中的示例代碼講解詳細(xì),具有一定的學(xué)習(xí)價值,感興趣的小伙伴可以了解下2023-11-11EL調(diào)用Java方法_動力節(jié)點(diǎn)Java學(xué)院整理
簡單來說,我們在一個類中的某個方法,可以使用EL進(jìn)行調(diào)用,這個能被EL表達(dá)式調(diào)用的方法稱之為EL函數(shù),但是這種方式必須滿足兩點(diǎn)要求,具體哪兩點(diǎn),大家可以參考下本文2017-07-07Java日常練習(xí)題,每天進(jìn)步一點(diǎn)點(diǎn)(47)
下面小編就為大家?guī)硪黄狫ava基礎(chǔ)的幾道練習(xí)題(分享)。小編覺得挺不錯的,現(xiàn)在就分享給大家,也給大家做個參考。一起跟隨小編過來看看吧,希望可以幫到你2021-08-08最新評論