文本來自StackOverflow問答網站的一個熱門討論：如何用Java編寫一段會發生內存泄露的代碼。

Q：剛才我參加了面試，面試官問我如何寫出會發生內存泄露的Java代碼。這個問題我一點思路都沒有，好囧。

A1：通過以下步驟可以很容易產生內存泄露（程序代碼不能訪問到某些對象，但是它們仍然保存在內存中）:

應用程序創建一個長時間運行的線程（或者使用線程池，會更快地發生內存泄露）。線程通過某個類加載器（可以自定義）加載一個類。該類分配了大塊內存（比如new byte[1000000]），在某個靜態變量存儲一個強引用，然后在ThreadLocal中存儲它自身的引用。分配額外的內存new byte[1000000]是可選的(類實例泄露已經足夠了)，但是這樣會使內存泄露更快。線程清理自定義的類或者加載該類的類加載器。重復以上步驟。

由于沒有了對類和類加載器的引用，ThreadLocal中的存儲就不能被訪問到。ThreadLocal持有該對象的引用，它也就持有了這個類及其類加載器的引用，類加載器持有它所加載的類的所有引用，這樣GC無法回收ThreadLocal中存儲的內存。在很多JVM的實現中Java類和類加載器直接分配到permgen區域不執行GC，這樣導致了更嚴重的內存泄露。

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

A2：

靜態變量引用對象

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

調用長字符串的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();

未關閉已打開流(文件，網絡等)

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

未關閉連接

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

JVM的GC不可達區域

比如通過native方法分配的內存。

web應用在application范圍的對象，應用未重啟或者沒有顯式移除

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

web應用在session范圍的對象，未失效或者沒有顯式移除

session.setAttribute("SOME_MAP", map);

不正確或者不合適的JVM選項

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

A3：如果HashSet未正確實現(或者未實現)hashCode()或者equals(),會導致集合中持續增加“副本”。如果集合不能地忽略掉它應該忽略的元素，它的大小就只能持續增長，而且不能刪除這些元素。

如果你想要生成錯誤的鍵值對，可以像下面這樣做：

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：除了被遺忘的監聽器，靜態引用，hashmap中key錯誤/被修改或者線程阻塞不能結束生命周期等典型內存泄露場景，下面介紹一些不太明顯的Java發生內存泄露的情況，主要是線程相關的。

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

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