文本來(lái)自StackOverflow問(wèn)答網(wǎng)站的一個(gè)熱門討論：如何用Java編寫(xiě)一段會(huì)發(fā)生內(nèi)存泄露的代碼。

Q：剛才我參加了面試，面試官問(wèn)我如何寫(xiě)出會(huì)發(fā)生內(nèi)存泄露的Java代碼。這個(gè)問(wèn)題我一點(diǎn)思路都沒(méi)有，好囧。

A1：通過(guò)以下步驟可以很容易產(chǎn)生內(nèi)存泄露（程序代碼不能訪問(wèn)到某些對(duì)象，但是它們?nèi)匀槐４嬖趦?nèi)存中）:

應(yīng)用程序創(chuàng)建一個(gè)長(zhǎng)時(shí)間運(yùn)行的線程（或者使用線程池，會(huì)更快地發(fā)生內(nèi)存泄露）。線程通過(guò)某個(gè)類加載器（可以自定義）加載一個(gè)類。該類分配了大塊內(nèi)存（比如new byte[1000000]），在某個(gè)靜態(tài)變量存儲(chǔ)一個(gè)強(qiáng)引用，然后在ThreadLocal中存儲(chǔ)它自身的引用。分配額外的內(nèi)存new byte[1000000]是可選的(類實(shí)例泄露已經(jīng)足夠了)，但是這樣會(huì)使內(nèi)存泄露更快。線程清理自定義的類或者加載該類的類加載器。重復(fù)以上步驟。

由于沒(méi)有了對(duì)類和類加載器的引用，ThreadLocal中的存儲(chǔ)就不能被訪問(wèn)到。ThreadLocal持有該對(duì)象的引用，它也就持有了這個(gè)類及其類加載器的引用，類加載器持有它所加載的類的所有引用，這樣GC無(wú)法回收ThreadLocal中存儲(chǔ)的內(nèi)存。在很多JVM的實(shí)現(xiàn)中Java類和類加載器直接分配到permgen區(qū)域不執(zhí)行GC，這樣導(dǎo)致了更嚴(yán)重的內(nèi)存泄露。

這種泄露模式的變種之一就是如果你經(jīng)常重新部署以任何形式使用了ThreadLocal的應(yīng)用程序、應(yīng)用容器（比如Tomcat）會(huì)很容易發(fā)生內(nèi)存泄露（由于應(yīng)用容器使用了如前所述的線程，每次重新部署應(yīng)用時(shí)將使用新的類加載器）。

A2：

靜態(tài)變量引用對(duì)象

class MemorableClass { static final ArrayList list = new ArrayList(100);}

調(diào)用長(zhǎng)字符串的String.intern()

String str=readString(); // read lengthy string any source db,textbox/jsp etc..// This will place the string in memory pool from which you cant removestr.intern();

未關(guān)閉已打開(kāi)流(文件，網(wǎng)絡(luò)等)

try { BufferedReader br = new BufferedReader(new FileReader(inputFile)); ... ...} catch (Exception e) { e.printStacktrace();}

未關(guān)閉連接

try { Connection conn = ConnectionFactory.getConnection(); ... ...} catch (Exception e) { e.printStacktrace();}

JVM的GC不可達(dá)區(qū)域

比如通過(guò)native方法分配的內(nèi)存。

web應(yīng)用在application范圍的對(duì)象，應(yīng)用未重啟或者沒(méi)有顯式移除

getServletContext().setAttribute("SOME_MAP", map);

web應(yīng)用在session范圍的對(duì)象，未失效或者沒(méi)有顯式移除

session.setAttribute("SOME_MAP", map);

不正確或者不合適的JVM選項(xiàng)

比如IBM JDK的noclassgc阻止了無(wú)用類的垃圾回收

A3：如果HashSet未正確實(shí)現(xiàn)(或者未實(shí)現(xiàn))hashCode()或者equals(),會(huì)導(dǎo)致集合中持續(xù)增加“副本”。如果集合不能地忽略掉它應(yīng)該忽略的元素，它的大小就只能持續(xù)增長(zhǎng)，而且不能刪除這些元素。

如果你想要生成錯(cuò)誤的鍵值對(duì)，可以像下面這樣做：

class BadKey { // no hashCode or equals(); public final String key; public BadKey(String key) { this.key = key; }} Map map = System.getProperties();map.put(new BadKey("key"), "value"); // Memory leak even if your threads die.

A4：除了被遺忘的監(jiān)聽(tīng)器，靜態(tài)引用，hashmap中key錯(cuò)誤/被修改或者線程阻塞不能結(jié)束生命周期等典型內(nèi)存泄露場(chǎng)景，下面介紹一些不太明顯的Java發(fā)生內(nèi)存泄露的情況，主要是線程相關(guān)的。

Runtime.addShutdownHook后沒(méi)有移除，即使使用了removeShutdownHook，由于ThreadGroup類對(duì)于未啟動(dòng)線程的bug，它可能不被回收，導(dǎo)致ThreadGroup發(fā)生內(nèi)存泄露。創(chuàng)建但未啟動(dòng)線程，與上面的情形相同創(chuàng)建繼承了ContextClassLoader和AccessControlContext的線程，ThreadGroup和InheritedThreadLocal的使用，所有這些引用都是潛在的泄露，以及所有被類加載器加載的類和所有靜態(tài)引用等等。這對(duì)ThreadFactory接口作為重要組成元素整個(gè)j.u.c.Executor框架(java.util.concurrent)的影響非常明顯，很多開(kāi)發(fā)人員沒(méi)有注意到它潛在的危險(xiǎn)。而且很多庫(kù)都會(huì)按照請(qǐng)求啟動(dòng)線程。ThreadLocal緩存，很多情況下不是好的做法。有很多基于ThreadLocal的簡(jiǎn)單緩存的實(shí)現(xiàn)，但是如果線程在它的期望生命周期外繼續(xù)運(yùn)行ContextClassLoader將發(fā)生泄露。除非真正必要不要使用ThreadLocal緩存。當(dāng)ThreadGroup自身沒(méi)有線程但是仍然有子線程組時(shí)調(diào)用ThreadGroup.destroy()。發(fā)生內(nèi)存泄露將導(dǎo)致該線程組不能從它的父線程組移除，不能枚舉子線程組。使用WeakHashMap，value直接(間接)引用key，這是個(gè)很難發(fā)現(xiàn)的情形。這也適用于繼承Weak/SoftReference的類可能持有對(duì)被保護(hù)對(duì)象的強(qiáng)引用。使用http(s)協(xié)議的java.net.URL下載資源。KeepAliveCache在系統(tǒng)ThreadGroup創(chuàng)建新線程，導(dǎo)致當(dāng)前線程的上下文類加載器內(nèi)存泄露。沒(méi)有存活線程時(shí)線程在第一次請(qǐng)求時(shí)創(chuàng)建，所以很有可能發(fā)生泄露。(在Java7中已經(jīng)修正了，創(chuàng)建線程的代碼合理地移除了上下文類加載器。)使用InflaterInputStream在構(gòu)造函數(shù)(比如PNGImageDecoder)中傳遞new java.util.zip.Inflater()，不調(diào)用inflater的end()。僅僅是new的話非常安全，但如果自己創(chuàng)建該類作為構(gòu)造函數(shù)參數(shù)時(shí)調(diào)用流的close()不能關(guān)閉inflater，可能發(fā)生內(nèi)存泄露。這并不是真正的內(nèi)存泄露因?yàn)樗鼤?huì)被finalizer釋放。但這消耗了很多native內(nèi)存，導(dǎo)致linux的oom_killer殺掉進(jìn)程。所以這給我們的教訓(xùn)是：盡可能早地釋放native資源。java.util.zip.Deflater也一樣，它的情況更加嚴(yán)重。好的地方可能是很少用到Deflater。如果自己創(chuàng)建了Deflater或者Inflater記住必須調(diào)用end()。

原文鏈接： stackoverflow 翻譯： ImportNew.com - hejiani