因此，我一直在尝试寻找一种好方法来监视 JVM 何时可能会出现 OOM 情况。他们似乎与我们的应用程序配合使用的最佳方法是通过 CMS 跟踪背靠背并发模式故障。这表明永久池填满的速度比它实际清理自身的速度快，或者回收的速度很少。
用于跟踪 GC 的 JMX bean 具有非常通用的信息，例如之前/之后的内存使用情况等。这些信息充其量是相对不一致的。有没有更好的方法可以监控 JVM 死亡的潜在警告信号？
So I've been trying to track down a good way to monitor when the JVM might potentially be heading towards an OOM situation. They best way that seems to work with our app is to track back-to-back concurrent mode failures through CMS. This indicates that the tenured pool is filling up faster than it can actually clean itself up, or its reclaiming very little.
The JMX bean for tracking GCs has very generic information such as memory usage before/after and the like. This information has been relatively inconsistent at best. Is there a better way I can be monitoring this potential warning sign of a dying JVM?
发布评论
评论（2）
假设您使用的是 Sun JVM，那么我知道有 2 个选项；
-gccause选项。您可以编写一个脚本来启动它并解析输出，或者理论上，您可以从主机 jvm（或另一个）生成一个进程，然后从 jstat 读取输出流以检测 gc 原因。但我认为原因报告并不是 100% 全面的。我不知道如何从 java 代码中以编程方式获取此信息。Assuming you're using the Sun JVM then I am aware of 2 options;
-gccauseoption. You can either write a script to launch this and parse the output or, theoretically, you could spawn a process from the host jvm (or another one) that then reads the output stream from jstat to detect the gc causes. I don't think the cause reporting is 100% comprehensive though. I don't know a way to get this info programatically from java code.使用标准 JRE 1.6 GC，随着垃圾收集器运行的频率越来越低，堆利用率可能会随着时间的推移而呈上升趋势，具体取决于应用程序的性质和指定的最大堆大小。也就是说，在没有更多信息的情况下很难判断发生了什么。
进一步研究的几种方法：
您可以在应用程序运行时使用 jmap 进行堆转储，然后使用 jhat 检查堆以查看在任何给定时间堆中存在哪些对象。
您还可以使用 -XX:+HeapDumpOnOutOfMemoryError 运行应用程序，这将在 JVM 遇到的第一个内存不足异常时自动进行堆转储。
您可以创建一个特定于您的应用程序的监视 bean，并创建可以使用远程 JMX 客户端访问的访问器方法。例如，返回队列和其他集合的大小的方法，这些集合可能是程序中内存使用的地方。
华泰
With standard JRE 1.6 GC, heap utilization can trend upwards overtime with the garbage collector running less and less frequently depending on the nature of your application and your maximum specified heap size. That said, it is hard to say what is going on without having more information.
A few methods to investigate further:
You could take a heap dump of your application while it is running using jmap, and then inspect the heap using jhat to see which objects are in heap at any given time.
You could also run your application with -XX:+HeapDumpOnOutOfMemoryError which will automatically make a heap dump on the first out of memory exception that the JVM encounters.
You could create a monitoring bean specific to your application, and create accessor methods you can hit with a remote JMX client. For example methods to return the sizes of queues and other collections that are likely places of memory utilization in your program.
HTH