Java中的內存泄漏
Java.Lang.OutOfMemoryError: Java Heap Space
Java應用程序只允許使用有限的內存。此限制在應用程序啟動期間指定。為了使事情更復雜，Java內存被分成兩個不同的區域。這些區域稱為永久生成區域（permgene和Permgen）：
這些區域的大小是在Java虛擬機（JVM）啟動期間設置的，可以通過指定JVM參數-Xmx和-XX:MaxPermSize進行定制。如果未顯式設置大小，則將使用特定于平臺的默認值。
這個java.lang.OutOfMemoryError：當應用程序嘗試向堆空間區域添加更多數據，但空間不足時，將觸發Java堆空間錯誤。
請注意，可能有大量可用的物理內存，但是java.lang.OutOfMemoryError：每當JVM達到堆大小限制時，就會拋出Java堆空間錯誤。
是什么引起內存泄露的？
最常見的原因是java.lang.OutOfMemoryError：Java heap space error ?您嘗試將XXL應用程序放入S大小的Java堆空間中。只是Java應用程序需要更多的空間來操作。此OutOfMemoryError消息的其他原因更為復雜，是由編程錯誤引起的：
使用量/數據量激增。該應用程序設計為處理一定數量的用戶或一定數量的數據。當用戶數量或數據量突然達到峰值并超過預期閾值時，在峰值停止運行并觸發java.lang.OutOfMemoryError：Java堆空間錯誤。 內存泄漏。特定類型的編程錯誤將導致應用程序不斷消耗更多內存。每次使用應用程序的泄漏功能時，它都會將一些對象留在Java堆空間中。隨著時間的推移，泄漏的對象會消耗所有可用的Java堆空間，并觸發已經熟悉的java.lang.OutOfMemoryError：Java堆空間錯誤。內存泄漏代碼示例
第一個例子非常簡單?下面的Java代碼嘗試分配一個2M整數數組。當您編譯它并使用12MB的Java堆空間（Java-Xmx12m-OOM）啟動時，它將失敗java.lang.OutOfMemoryError：Java堆空間消息。有了13MB的Java堆空間，程序運行得很好。
class OOM { static final int SIZE=2*1024*1024; public static void main(String[] a) { int[] i = new int[SIZE]; }}
第二個也是更現實的例子是內存泄漏在Java中，當開發人員創建和使用新的對象（如new Integer（5））時，他們不必自己分配內存—這是由Java虛擬機（JVM）負責的。在應用程序的生命周期中，JVM會定期檢查內存中哪些對象仍在使用，哪些對象沒有使用。未使用的對象可以丟棄，內存可以回收并再次使用。這個過程稱為垃圾回收。JVM中負責收集的相應模塊稱為垃圾收集器（GC）。
Java的自動內存管理依賴于GC定期查找未使用的對象并將其刪除。簡單地說，java 內存泄露是指應用程序不再使用某些對象，但垃圾回收無法識別它的情況。因此，這些未使用的對象將無限期地保留在Java堆空間中。這起連環碰撞最終會觸發java.lang.OutOfMemoryError：Java堆空間錯誤。
構建一個滿足內存泄漏定義的Java程序相當容易：
class KeylessEntry { static class Key { Integer id; Key(Integer id) { this.id = id; } @Override public int hashCode() { return id.hashCode(); } } public static void main(String[] args) { Map m = new HashMap(); while (true) for (int i = 0; i < 10000; i++) if (!m.containsKey(new Key(i)))m.put(new Key(i), 'Number:' + i); }}
當您執行上面的代碼時，您可能希望它永遠運行而不會出現任何問題，假設天真的緩存解決方案只將底層映射擴展到10000個元素，除此之外，所有的鍵都已經存在于HashMap中。但是，實際上，由于Key類在hashCode()旁邊沒有適當的equals()實現，所以元素將繼續被添加。
結果，隨著時間的推移，隨著泄漏代碼的不斷使用，“緩存”結果最終會消耗大量Java堆空間。當泄漏的內存填滿堆區域中的所有可用內存，而垃圾回收無法清理它時java.lang.OutOfMemoryError：引發Java堆空間。
解決方案很簡單?添加與下面類似的equals()方法的實現，您就可以開始了。但在你找到病因之前，你肯定會失去一些珍貴的腦細胞。
@Overridepublic boolean equals(Object o) { boolean response = false; if (o instanceof Key) { response = (((Key)o).id).equals(this.id); } return response;}
內存溢出怎么解決?
在某些情況下，分配給JVM的堆的數量不足以滿足在JVM上運行的應用程序的需要。在這種情況下，您應該只分配更多的堆—請參閱本章末尾的部分了解如何實現這一點。
然而，在許多情況下，提供更多的Java堆空間并不能解決問題。例如，如果應用程序包含內存泄漏，則添加更多堆只會推遲java.lang.OutOfMemoryError：Java堆空間錯誤。此外，增加Java堆空間量也會增加GC暫停的長度，從而影響應用程序的吞吐量或延遲。
如果您希望解決Java堆空間的底層問題，而不是掩蓋癥狀，那么您需要找出代碼的哪一部分負責分配最多的內存。換句話說，你需要回答以下問題：
哪些對象占據堆的大部分 在源代碼中分配這些對象在這一點上，一定要在你的日歷中清除幾天（或者-在項目符號列表下面自動查看）。下面是一個粗略的流程大綱，可以幫助您回答上述問題：
獲得安全許可，以便從JVM執行堆轉儲。“dump轉儲”基本上是堆內容的快照，您可以對其進行分析。因此，這些快照可能包含機密信息，如密碼、信用卡號碼等，因此出于安全原因，獲取此類轉儲甚至可能不可能。 在適當的時候把垃圾處理掉。準備好獲取一些轉儲，因為當在錯誤的時間執行時，堆轉儲包含大量的噪聲，實際上可能是無用的。另一方面，每個堆轉儲都會完全“freezes凍結”JVM，所以不要占用太多，否則最終用戶將面臨性能問題。 找一臺能裝垃圾的機器。當您的JVM使用例如8GB的堆時，您需要一臺大于8GB的機器來分析堆內容。啟動轉儲分析軟件（我們推薦Eclipse MAT，但也有同樣好的替代品）。 檢測堆的最大使用者的GC根路徑。我們在這里的另一篇文章中討論了這一活動。這對初學者來說尤其困難，但實踐將使你了解結構和導航機制。 接下來，您需要弄清楚源代碼中潛在危險的大量對象被分配到哪里。如果您對應用程序的源代碼有很好的了解，那么您將能夠在幾次搜索中做到這一點。或者，我們建議使用plumber，這是唯一一個具有自動根本原因檢測功能的Java監控解決方案。在其他性能問題中，它包羅萬象java.lang.OutOfMemoryErrors并自動為您提供有關最需要內存的數據結構的信息。
Plumber負責在后臺收集必要的數據——這包括關于堆使用情況的相關數據（只有對象布局圖，沒有實際數據），還有一些甚至在堆轉儲中都找不到的數據。它還為您執行必要的數據處理—在運行中，只要JVM遇到java.lang.OutOfMemoryError. 這里有一個例子java.lang.OutOfMemoryError管道工事故警報：
無需任何其他工具或分析，您可以看到：
哪些對象消耗的內存最多 在哪里分配這些對象（它們中的大多數在MetricManagerImpl類中分配，第304行） 當前引用這些對象的是什么（到GC根的完整引用鏈）有了這些信息，您就可以放大潛在的根本原因，并確保將數據結構縮減到適合您的內存池的級別。
然而，當您從內存分析或閱讀plumber報告得出的結論是內存使用是合法的，并且源代碼中沒有什么可更改的，那么您需要允許JVM有更多的Java堆空間來正常運行。在這種情況下，更改JVM啟動配置并添加（或增加值，如果存在）：
-Xmx1024m
上述配置將為應用程序提供1024MB的Java堆空間。可以使用g或g表示GB，m或m表示MB，k或k表示KB。例如，以下所有內容都相當于最大Java堆空間為1GB：
java -Xmx1073741824 com.mycompany.MyClass java -Xmx1048576k com.mycompany.MyClass java -Xmx1024m com.mycompany.MyClass java -Xmx1g com.mycompany.MyClass
以上就是Java中的內存泄漏的詳細內容，更多關于Java 內存泄漏的資料請關注好吧啦網其它相關文章！
相關文章：
網公網安備