有没有通过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代码中以编程方式获取此信息的方法。