有沒有通過JMX識別CMS併發模式故障的方法？

Question

所以我一直在試圖找到一種很好的方法來監視JVM何時可能正朝着OOM的方向發展。他們似乎與我們的應用程序一起工作的最好方式是通過CMS跟蹤背靠背併發模式故障。這表明終端游泳池的填充速度比實際清理自己的速度要快，或者其回收量很少。

用於跟蹤GC的JMX bean具有非常通用的信息，例如之前/之後的內存使用情況等。這個信息充其量是相對不一致的。有沒有更好的方法可以監控死亡JVM的這種潛在警告信號？

Answer 1

對於標準的JRE 1.6 GC，根據應用程序的性質和最大指定堆大小，堆使用率可能會隨着垃圾收集器運行的頻率越來越低而超時運行。也就是說，如果沒有更多的信息，很難說正在發生什麼。

的幾種方法，以進一步調查：

它使用JMAP運行時，你可以把你的應用程序的堆轉儲，然後用與jHat，看看哪些對象是在堆在任何給定的時間檢查堆。

您也可以使用-XX：+ HeapDumpOnOutOfMemoryError運行應用程序，該應用程序將在JVM遇到的第一次內存不足異常時自動進行堆轉儲。

您可以創建特定於您的應用程序的監視bean，並創建可以使用遠程JMX客戶端訪問的訪問器方法。例如，返回可能在您的程序中使用內存的隊列和其他集合的大小的方法。

HTH

Answer 2

假設您使用的是Sun JVM，那麼我知道有兩個選項;

1. 內存管理的MXBean（API裁判開始here），你似乎已正在使用但要注意有一些熱點特定內部的人，你可以訪問，看到this blog對於如何使用
2. jstat爲例：cmd參考是here，您需要-gccause選項。你可以寫一個腳本來啓動它並解析輸出，或者理論上你可以從主機jvm（或另一個）產生一個進程，然後從jstat讀取輸出流來檢測gc的原因。我不認爲原因報告是100％全面的。我不知道從java代碼中以編程方式獲取此信息的方法。