java - 有没有办法通过 JMX 识别 CMS 并发模式故障?

标签 java garbage-collection concurrent-mark-sweep

因此,我一直在尝试寻找一种好方法来监视 JVM 何时可能会出现 OOM 情况。他们似乎与我们的应用程序配合使用的最佳方法是通过 CMS 跟踪背靠背并发模式故障。这表明永久池的填满速度比它实际清理自身的速度要快,或者它的回收很少。

用于跟踪 GC 的 JMX bean 具有非常通用的信息,例如之前/之后的内存使用情况等。这些信息充其量是相对不一致的。有没有更好的方法可以监视 JVM 死亡的潜在警告信号?

最佳答案

假设您使用的是 Sun JVM,那么我知道有 2 个选项;

  1. 内存管理 mxbeans(API 引用从 here 开始),您似乎已经在使用它,但请注意,您可以访问一些特定于热点的内部组件,请参阅 this blog有关如何使用的示例
  2. jstat:cmd 引用是 here ,您将需要 -gccause 选项。您可以编写一个脚本来启动它并解析输出,或者理论上,您可以从主机 jvm(或另一个)生成一个进程,然后从 jstat 读取输出流以检测 gc 原因。但我认为原因报告并不是 100% 全面的。我不知道如何从 java 代码中以编程方式获取此信息。

关于java - 有没有办法通过 JMX 识别 CMS 并发模式故障?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/5476661/

相关文章:

java - 有人使用 Eclipse 成功构建了 Bruce Eckels 的 'Thinking in java' 第四版吗?

将对象设置为 null 时的 JavaScript(ES6) WeakMap 垃圾回收

Java:使用 jlibs 保证垃圾收集

java - CMS 垃圾收集器——它什么时候运行?

java - 包 org.jetbrains.annotations 不存在

java - JPEG 图像颜色错误

java - 当这个新的Thread()在Android中被GC时?

java - -XX+UseCMSCompactAtFullCollection 的确切用途是什么?

java - 并发标记清除收集发生得不够频繁

java - 多线程代码中的非 volatile 状态标志