hotspot jvm

由于內(nèi)存泄漏或其他內(nèi)存問題，經(jīng)常導致應用程序凍結，僅使垃圾收集器（GC）進程運行失敗，試圖釋放一些空間。 直到看門狗（或沮喪的管理員）重新啟動應用程序并且問題從未解決之前，這種情況一直發(fā)生。 本文的目的是展示如何識別過多的GC并在發(fā)生堆轉儲時獲取堆轉儲。 假定Hotspot JVM 1.6或更高版本。 相關的JVM標志 使用以下標志，我們可以指示Hotspot JVM在應用程序變?yōu)镚C驅動時引發(fā)堆轉儲。 首先，應添加-XX：+ HeapDumpOnOutOfMemoryError標志。 我們的目標是在由于不停止GC而導致應用程序吞吐量下降時生成OutOfMemory錯誤。 有兩個JVM標志將有幫助：

• -XX： GCTimeLimit = 98 –定義拋出OutOfMemory錯誤之前在GC中花費的時間比例的限制
• -XX： GCHeapFreeLimit = 2 –定義完整GC之后拋出OutOfMemoryError之前的最小可用空間百分比

默認情況下，兩個標志都是啟用的，但是內(nèi)存不足錯誤不會經(jīng)常觸發(fā)。 因此，需要更深入的了解才能確定每個標志何時有用以及默認值是什么。 Oracle文檔 ? 過多的GC時間和OutOfMemoryError。 如果在垃圾回收上花費了太多時間，則并發(fā)收集器將拋出OutOfMemoryError：如果在垃圾回收上花費了總時間的98％以上，而回收的堆少于2％，則將拋出OutOfMemoryError。 此功能旨在防止應用程序長時間運行，而由于堆太小而幾乎沒有進展，甚至沒有進展。 如有必要，可以通過在命令行中添加選項-XX：-UseGCOverheadLimit來禁用此功能。 該策略與并行收集器中的策略相同，除了執(zhí)行并發(fā)收集所花費的時間不計入98％的時間限制。 換句話說，只有在應用程序停止時執(zhí)行的收集才計入過多的GC時間。 此類收集通常是由于并發(fā)模式故障或顯式收集請求（例如，對System.gc（）的調(diào)用）引起的。 如第二段所述， GCTimeLimit在并行收集器上不能很好地工作，因為在這種情況下花費在GC上的時間不太重要。 為GCHeapFreeLimit選擇默認值 ? 選擇默認值的方式應使當應用程序變得無響應（或由GC驅動）時，將導致內(nèi)存不足。 無響應性是一個主觀定義，可能因應用程序而異，因此對于不同的應用程序，其結果值可能會（略有不同）不同。 首先，應該創(chuàng)建一個簡單的測試。 在應用程序內(nèi)部運行并分配大量對象的類。 可以快速收集部分對象，并且可以長期保留部分對象。 在運行測試之前，應添加GC日志記錄標志。 對于我的應用程序，添加了以下標志： -Xmx960m-詳細：gc -XX：+ PrintGCDetails -XX：+ PrintGCDateStamps -XX：+ PrintTenuringDistribution -Xloggc：/root/gc.log -XX：+ HeapDumpOnOutOfMemoryError -XX：HeapDumpPath = / root / dumps GC日志的輸出如下所示。 第一個完整的GC周期–應用程序具有響應能力： [完整GC [PSYoungGen：290112K-> 33213K（308672K）] [PSOldGen：655359K-> 655359K（655360K）] 945471K-> 688573K（964032K）] 幾分鐘后–應用程序無響應： [完整GC [PSYoungGen：290112K-> 213269K（308672K）] [PSOldGen：655359K-> 655359K（655360K）] 945471K-> 868629K（964032K）] 對于950 Mb堆，內(nèi)存空間的分布為：老gen = 650Mb，年輕= 300Mb。 當應用程序響應時，老一代將充滿強大的參考數(shù)據(jù)，而大多數(shù)年輕一代則是垃圾。 因此，GCHeapFreeLimit的一個估計是（清除所有年輕人，不清除任何舊東西）300/950?32％。 但是，隨著時間的流逝，無法將年輕空間中的物體提升為舊空間，因為空間已滿。 就像在Oracle文檔中所說的那樣： 最年輕的集合并不需要保證完全升級所有活動對象。 （-XX：+ HandlePromotionFailure標志）。 由于促銷失敗，因此引用的對象比年輕一代期望的要多得多。 為了安全起見（減少誤報），我假設當年輕空間的1/3以上是垃圾空間而舊空間已滿時，系統(tǒng)由GC驅動。 因此，我建議類似我的應用的比率是200/950?20％。 -XX： GCHeapFreeLimit = 20 實驗表明，OOM在超出20％限制的1-2分鐘過量GC后發(fā)生，在此期間發(fā)生30-35個完整GC。 結論 在沒有靈丹妙藥的Java中，識別過多的垃圾回收是一項艱巨的任務。 熱點JVM開發(fā)人員提供了一些方法，這些方法將經(jīng)常有助于識別根本原因。 如果正確使用GCHeapFreeLimit和GCTimeLimit標志，可以使用適當?shù)闹祦黻U明問題。 參考資料 1. http://www.oracle.com/technetwork/java/javase/tech/vmoptions-jsp-140102.html 2. http://www.oracle.com/technetwork/java/javase/gc-tuning-6-140523.html 參考：來自The Art of Java博客的JCG合作伙伴 Art Gourevitch 在Hotspot JVM中跟蹤過多的垃圾收集 。

翻譯自: https://www.javacodegeeks.com/2012/06/tracking-excessive-garbage-collection.html

hotspot jvm

總結

以上是生活随笔為你收集整理的hotspot jvm_在Hotspot JVM中跟踪过多的垃圾收集的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。