1. 簡介

Java的核心優勢之一是在內置垃圾收集器(簡稱GC)的幫助下實現自動內存管理。GC隱含地負責分配和釋放內存，因此能夠處理大多數內存泄漏問題。

雖然GC有效地處理了大部分內存，但它并不能成為保證內存泄漏的萬無一失的解決方案。GC很聰明，但并不完美。即使在盡職盡責的開發人員的應用程序中，內存仍然可能會泄漏。

仍然可能存在應用程序生成大量多余對象的情況，從而耗盡關鍵內存資源，有時會導致整個應用程序失敗。

內存泄漏是Java中的一個真實存在的問題。在本教程中，我們將了解內存泄漏的潛在原因是什么，如何在運行時識別它們，以及如何在我們的應用程序中處理它們。

2. 什么是內存泄漏

內存泄漏是堆中存在不再使用的對象但垃圾收集器無法從內存中刪除它們的情況，因此它們會被不必要地一直存在。

內存泄漏很糟糕，因為它會耗盡內存資源并降低系統性能。如果不處理，應用程序最終將耗盡其資源，最終以致命的java.lang.OutOfMemoryError終止。

堆內存中有兩種不同類型的對象 - 被引用和未被引用。被引用的對象是在應用程序中仍具有活動引用的對象，而未被引用的對象沒有任何的活動引用。

垃圾收集器會定期刪除未引用的對象，但它永遠不會收集仍在引用的對象。這是可能發生內存泄漏的地方：

內存泄漏的癥狀

• 應用程序長時間連續運行時性能嚴重下降
• 應用程序中的OutOfMemoryError堆錯誤
• 自發且奇怪的應用程序崩潰
• 應用程序偶爾會耗盡連接對象

讓我們仔細看看其中一些場景以及如何處理它們。

3. Java中內存泄漏類型

在任何應用程序中，數不清的原因可能導致內存泄漏。在本節中，我們將討論最常見的問題。

3.1 static字段引起的內存泄漏

可能導致潛在內存泄漏的第一種情況是大量使用static(靜態)變量。

在Java中，靜態字段通常擁有與整個應用程序相匹配的生命周期(除非 ClassLoader復合垃圾回收的條件)。

讓我們創建一個填充靜態列表的簡單Java程序：

public class StaticTest { public static List list = new ArrayList<>(); public void populateList() { for (int i = 0; i < 10000000; i++) { list.add(Math.random()); } Log.info("Debug Point 2"); } public static void main(String[] args) { Log.info("Debug Point 1"); new StaticTest().populateList(); Log.info("Debug Point 3"); }}

現在如果我們在程序中分析堆內存，我們會發現在調試點1和2之間，和預期中的一樣，對內存增加了。

但當我們在調試點3，離開 populateList()方法時，堆內存并沒有被垃圾回收，正如我們在 VisualVM響應中看到的一樣：

但是，在上面的程序中，在第2行中，如果我們只刪除關鍵字 static，那么它將對內存使用量帶來巨大的變化，這個 VisualVM響應顯示：

直到調試點的第一部分幾乎與我們在 static情況下獲得的部分相同 。但這次當我們離開 populateList()方法，列表中所有的內存都被垃圾回收掉了，因為我們沒有任何對他的引用。

因此，我們需要非常關注static(靜態)變量的使用。如果集合或大對象被聲明為static，那么它們將在應用程序的整個生命周期中保留在內存中，從而阻止可能在其他地方使用的重要內存。

如何預防呢？

• 最大限度地減少靜態變量的使用
• 使用單例時，依賴于延遲加載對象而不是立即加載的方式

3.2 未關閉的資源導致的內存泄漏

每當我們創建連接或打開一個流時，JVM都會為這些資源分配內存。例如數據庫連接，輸入流或者會話對象。

忘記關閉這些資源會導致持續占有內存，從而使他們無法GC。如果異常阻止程序執行到達處理關閉這些資源的代碼，則甚至可能發生這種情況。

在任一種情況下，資源留下的開放連接都會消耗內存，如果我們不處理他們，他們可能會降低性能，甚至可能導致 OutOfMemoryError。

如何預防呢？

• 始終使用 finally塊來關閉資源
• 關閉資源的代碼(甚至在 finally塊中)本身不應該有任何異常
• 使用Java 7+時，我們可以使用 try-with-resources塊

3.3 不正確的 equals()和 hashCode()實現

在定義新類時，一個非常常見的疏忽是不為 equals()和 hashCode()方法編寫適當的重寫方法。

HashSet 和 HashMap 在許多操作中使用這些方法，如果它們沒有被正確覆蓋，那么它們可能成為潛在的內存泄漏問題的來源。

讓我們以一個簡單的 Person 類為例， 并將其用作 HashMap中的鍵 ：

public class Person { public String name; public Person(String name) { this.name = name; }}

現在我們將重復的Person對象插入到使用此鍵的Map中。

請記住，Map不能包含重復的鍵：

@Testpublic void givenMap_whenEqualsAndHashCodeNotOverridden_thenMemoryLeak() { Map map = new HashMap<>(); for(int i=0; i<100; i++) { map.put(new Person("jon"), 1); } Assert.assertFalse(map.size() == 1);}

這里我們使用Person作為關鍵。由于 Map不允許重復鍵，因此我們作為鍵插入的眾多重復 Person對象不應增加內存。

但是由于我們沒有定義正確的equals()方法，重復的對象會堆積并增加內存，這就是我們在內存中看到多個對象的原因。VisualVM中的堆內存如下所示：

但是，**如果我們正確地重寫了 equals() 和 hashCode()方法，那么在這個 Map中只會存在一個 Person對象。

讓我們看一下正確的實現了 equals()和 hashCode()的 Person類：

public class Person { public String name; public Person(String name) { this.name = name; } @Override public boolean equals(Object o) { if (o == this) return true; if (!(o instanceof Person)) { return false; } Person person = (Person) o; return person.name.equals(name); } @Override public int hashCode() { int result = 17; result = 31 * result + name.hashCode(); return result; }}

在這種情況下，下面的斷言將會是true：

@Testpublic void givenMap_whenEqualsAndHashCodeNotOverridden_thenMemoryLeak() { Map map = new HashMap<>(); for(int i=0; i<2; i++) { map.put(new Person("jon"), 1); } Assert.assertTrue(map.size() == 1);}

在適當的重寫 equals()和 hashCode()之后，堆內存在同一程序中如下所示：

另一個例子是當使用像 hibernate這樣的ORM框架，他們使用 equals()和 hashCode()方法去分析對象然后將他們保存在緩存中。

如何預防呢？

• 根據經驗，定義新的實體時，總要重寫 equals()和 hashCode()方法。
• 只是重寫他們是不夠的，這些方法必須以最佳的方式被重寫。

有關更多信息，請訪問我們的 Generate equals() and hashCode() with Eclipse 和Guide to hashCode() in Java。

3.4引用了外部類的內部類

這種情況發生在非靜態內部類(匿名類)的情況下。對于初始化，這些內部類總是需要外部類的實例。

默認情況下，每個非靜態內部類都包含對其包含類的隱式引用。如果我們在應用程序中使用這個內部類'對象，那么即使在我們的包含類'對象超出范圍之后，它也不會被垃圾收集。

考慮一個類，它包含對大量龐大對象的引用，并具有非靜態內部類。現在，當我們創建一個內部類的對象時，內存模型如下所示：

但是，如果我們只是將內部類聲明為static，那么相同的內存模型如下所示：

發生這種情況是因為內部類對象隱式地保存對外部類對象的引用，從而使其成為垃圾收集的無效候選者。在匿名類的情況下也是如此。

如何預防呢？

• 如果內部類不需要訪問包含的類成員，請考慮將其轉換為靜態類

3.5 finalize()方法造成的內存泄漏

使用 finalizers是潛在的內存泄漏問題的另一個來源。每當重寫類的 finalize()方法時，該類的對象不會立即被垃圾收集。相反，GC將它們排隊等待最終確定，這將在稍后的時間點發生。

另外，如果用 finalize()方法編寫的代碼不是最佳的，并且終結器隊列無法跟上Java垃圾收集器，那么遲早，我們的應用程序注定要遇到 OutOfMemoryError。

為了證明這一點，讓我們考慮一下我們已經覆蓋了 finalize()方法的類，并且該方法需要一些時間來執行。當這個類的大量對象被垃圾收集時，那么在VisualVM中，它看起來像：

但是，如果我們只刪除重寫的finalize()方法，那么同一程序會給出以下響應：

如何預防呢？

• 我們應該總是避免 finalizers

有關finalize()的更多詳細信息，請閱讀我們的 Guide to the finalize Method in Java 第3節(避免終結器) 。

常量字符串造成的內存泄漏

Java String池Java 7時經歷了在從永生代(PermGen)轉移到堆空間(HeapSpace)的重大變化。但是對于在版本6及更低版本上運行的應用程序，在使用大型字符串時我們應該更加專心。

如果我們讀取一個龐大的大量String對象，并在該對象上調用intern()，那么它將轉到字符串池，它位于PermGen(永生代)中，并且只要我們的應用程序運行就會保留在那里。這會占用內存并在我們的應用程序中造成重大內存泄漏。

JVM 1.6中這種情況的PermGen在VisualVM中看起來像這樣：

與此相反，在一個方法中，如果我們只是從文件中讀取一個字符串而不是 intern()，那么PermGen看起來像：

如何預防呢？

• 
  解決此問題的最簡單方法是升級到最新的Java版本，因為String池從Java版本7開始轉移到HeapSpace
• 
  如果處理大型字符串，請增加PermGen空間的大小以避免任何潛在的OutOfMemoryErrors：
• -XX:MaxPermSize=512m

3.7 使用 ThreadLocal造成的內存泄漏

ThreadLocal (在Introduction to ThreadLocal in Java 中詳細介紹)，是一種能將狀態隔離到特定線程，從而保證我們實現線程安全的結構。

使用此結構時，每個線程只要處于存活狀態即可將保留對其ThreadLocal變量副本的隱式引用，并且將保留其自己的副本，而不是跨多個線程共享資源。

盡管有其優點，ThreadLocal 變量的使用仍存在爭議，因為如果使用不當，它們會因引入內存泄漏而臭名昭著。Joshua Bloch once commented on thread local usage：

“Sloppy use of thread pools in combination with sloppy use of thread locals can cause unintended object retention, as has been noted in many places. But placing the blame on thread locals is unwarranted.”

"隨意的在線程池中使用 ThreadLocal會保留很多意外的對象。但把責任歸咎于 ThreadLocal是沒有根據的 "

ThreadLocal中的內存泄漏

一旦保持線程不再存在， ThreadLocals應該被垃圾收集。但是當 ThreadLocals與現代應用程序服務器一起使用時，問題就出現了。

現代應用程序服務器使用線程池來處理請求而不是創建新請求(例如在Apache Tomcat的情況下為Executor)。此外，他們還使用單獨的類加載器。

由于應用程序服務器中的線程池在線程重用的概念上工作，因此它們永遠不會被垃圾收集 - 相反，它們會被重用來處理另一個請求。

現在，如果任何類創建 ThreadLocal 變量但未顯式刪除它，則即使在Web應用程序停止后，該對象的副本仍將保留在工作線程中，從而防止對象被垃圾回收。

如何預防呢？

• 
  在不再使用 ThreadLocals時清理 ThreadLocals是一個很好的做法- ThreadLocals提供了 remove()方法，該方法刪除了此變量的當前線程值
• 不要使用 ThreadLocal.set(null) 來清除該值 - 它實際上不會清除該值，而是查找與當前線程關聯的 Map并將鍵值對設置為當前線程并分別為null
• 
  最好將 ThreadLocal 視為需要在 finally塊中關閉的資源，以 確保它始終關閉，即使在異常的情況下：
• try{
• threadLocal.set(System.nanoTime());
• //... further processing
• }
• finally{
• threadLocal.remove();
• }

4. 處理內存泄漏的其他策略

雖然在處理內存泄漏時沒有一個通用的解決方案，但有一些方法可以最大限度地減少這些泄漏。

4.1 使用 Profiling工具

Java分析器是通過應用程序監視和診斷內存泄漏的工具。他們分析我們的應用程序內部發生了什么 - 例如，如何分配內存。

使用分析器，我們可以比較不同的方法，并找到我們可以最佳地使用我們的資源的領域。

我們在本教程的第3部分中使用了Java VisualVM。請查看我們的 Java Profilers指南， 了解不同類型的分析器，如Mission Control，JProfiler，YourKit，Java VisualVM和Netbeans Profiler。

4.2 詳細垃圾回收

通過啟用詳細垃圾收集，我們將跟蹤GC的詳細跟蹤。要啟用此功能，我們需要將以下內容添加到JVM配置中：

通過添加此參數，我們可以看到GC內部發生的詳細信息：

4.3 使用引用對象避免內存泄漏

我們還可以使用java中的引用對象來構建 java.lang.ref包來處理內存泄漏。使用 java.lang.ref包，我們使用對象的特殊引用，而不是直接引用對象，這些對象可以很容易地進行垃圾回收。

引用隊列旨在讓我們了解垃圾收集器執行的操作。有關更多信息，請閱讀Baeldung的 Soft References in Java ，特別是第4節。

Eclipse的內存泄漏警告

對于JDK 1.5及更高版本的項目，Eclipse會在遇到明顯的內存泄漏情況時顯示警告和錯誤。因此，在Eclipse中開發時，我們可以定期訪問“問題”選項卡，并對內存泄漏警告(如果有)更加警惕：

4.5 基準分析

我們可以通過執行基準來測量和分析Java代碼的性能。這樣，我們可以比較替代方法的性能來完成相同的任務。這可以幫助我們選擇更好的方法，并可以幫助我們節約內存。

有關基準測試的更多信息，請訪問我們的 Microbenchmarking with Java 教程。

4.6 代碼審核

最后，我們總是采用經典懷舊方式進行簡單的代碼審核。

在某些情況下，即使是這種微不足道的方法也可以幫助消除一些常見的內存泄漏問題。

5 結論

通俗地說，我們可以將內存泄漏視為一種通過阻止重要內存資源來降低應用程序性能的疾病。和所有其他疾病一樣，如果不治愈，它可能導致致命的應用程序崩潰隨著時間的推移。

內存泄漏很難解決，找到它們需要通過Java語言進行復雜的掌握和命令。在處理內存泄漏時，沒有一個通用的解決方案，因為泄漏可能通過各種各樣的事件發生。

但是，如果我們采用最佳實踐并定期執行嚴格的代碼演練和分析，那么我們可以最大程度地降低應用程序中內存泄漏的風險。

Java初學者福利，在入門學習Java的過程當中有缺乏基礎的視頻教程，可以申請加入我的Java交流學習群:308139472，進群備注2，群里有最新的Java精講基礎視頻，Java學習手冊，面試題，Java開發工具，PDF文檔教程等，需要的都可以自行來下載。

總結

以上是生活随笔為你收集整理的java 内存泄漏_Java开发者必须知道的内存泄漏问题的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。