如何用java寫一段程式碼引發記憶體洩露

　文字來自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 remove
str.intern();

未關閉已開啟流(文件，網路等)

reee達區域

　　例如透過native方法分配的記憶體。

　　web應用在application範圍的對象，應用未重啟或沒有明確移除

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

〜『移除

　　session.setAttribute("SOME_MAP", map);

　　不正確或不合適的JVM選項

　　例如IBM JDK的noclassgcc『未實作)hashCode()或equals(),會導致集合中持續增加「副本」。如果集合不能地忽略掉它應該忽略的元素，它的大小就只能持續成長，而且不能刪除這些元素。

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

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

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()。