使用最新的 Sun JVM (1.6),是否可以获得 GC 线程信息?
使用 JRockit,您可以通过任何方式获取完整的线程列表,所有这些方式都包含有关垃圾收集线程的信息:
1) 向 Thread
类询问信息:
Thread.getAllStackTraces();
2)使用 ThreadGroup 获取该信息:
ThreadGroup root = Thread.currentThread().getThreadGroup();
while (root.getParent() != null) {
root = root.getParent();
}
Thread[] list = new Thread[root.activeCount() + 5];
root.enumerate(list, true);
3) 使用 JMX 获取列表:
ThreadMXBean THREAD_MX_BEAN = ManagementFactory.getThreadMXBean();
long[] tids = THREAD_MX_BEAN.getAllThreadIds();
ThreadInfo[] tinfos = THREAD_MX_BEAN.getThreadInfo(tids);
4) CTRL-BREAK
但是,使用 Sun JVM(至少是最近的 Java 6 版本)似乎只有 CTRL-BREAK包括垃圾收集线程和VM定期任务线程。我发现监视 GC 线程使用的 CPU 很有用,这样我的应用程序就可以检测并记录 GC 何时使用大部分 CPU 时间。如果没有此信息,您只能知道 GC 何时超过特定的设定阈值。
如果我什至只能找出 GC 线程的线程 ID,那么 JMX 可能会提供我需要的其余信息(除非这些线程有不同之处)。例如,使用以下方法:
long threadId = tids[0];
long cpuTime = THREAD_MX_BEAN.getThreadCpuTime(threadId);
有谁知道如何(或者如果已知不可能)使用 Sun JVM 获取有关垃圾收集线程的信息?
With JRockit, you can get the full list of threads by any means, and all of these means include information about the Garbage Collection Thread(s):
1) Asking the Thread
class for the information:
Thread.getAllStackTraces();
2) Using ThreadGroup
to get that information:
ThreadGroup root = Thread.currentThread().getThreadGroup();
while (root.getParent() != null) {
root = root.getParent();
}
Thread[] list = new Thread[root.activeCount() + 5];
root.enumerate(list, true);
3) Using JMX to get the list:
ThreadMXBean THREAD_MX_BEAN = ManagementFactory.getThreadMXBean();
long[] tids = THREAD_MX_BEAN.getAllThreadIds();
ThreadInfo[] tinfos = THREAD_MX_BEAN.getThreadInfo(tids);
4) CTRL-BREAK
However, using the Sun JVM -- at least recent Java 6 releases -- only CTRL-BREAK seems to include the Garbage Collection threads and the VM Periodic Task thread. I find it useful to monitor CPU used by the GC threads so my application can detect and log when GC is using most of the CPU time. Without this information, you only know when GC exceeds certain set thresholds.
If I can even just find out the Thread ID of the GC threads, then JMX will probably give the rest of the information I need (unless there is something different about these Threads). For example, using the method:
long threadId = tids[0];
long cpuTime = THREAD_MX_BEAN.getThreadCpuTime(threadId);
Does anyone know how -- or if it is known to be not possible -- to get information about the garbage collection Thread(s) using the Sun JVM?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
这是特定于 Java 1.5+ Sun (HotSpot) JVM 的。
在您要监视的 MBeanServer 中注册 MBean sun.management.HotspotInternal。 HotSpot 内部 mbean 的注册:
这将触发这些 HotspotThreading MBean 有一个名为InternalThreadCpuTimes 的属性,它是HotSpot 内部线程的映射。GC 线程可通过名称来识别。例如,在我现在运行的JVM中,它们被称为:
映射的值是每个线程的CPU时间。
HotSpotMemory MBean 还有一个名为 InternalMemoryCounters 的属性,其中包含一些有关 GC 的附加信息。
This is specific to the Java 1.5+ Sun (HotSpot) JVM.
Register the MBean sun.management.HotspotInternal in the MBeanServer you are looking to monitor from. This will trigger the registration of these HotSpot internal mbeans:
The HotspotThreading MBean has an attribute called InternalThreadCpuTimes which is a map of HotSpot's internal threads.The GC threads are identifiable by name. For example, in the JVM I am running right now, they are called:
The value of the map is the CPU time for each thread.
The HotSpotMemory MBean also has an attribute called InternalMemoryCounters which has a few additional bits of information about GC.
第一步是使用 verbosegc:
java -verbose:gc -XX:+PrintGCDetails
,它将为您提供一些有关 GC 操作所消耗的(挂钟)时间以及操作类型(完整或增量)的信息。你的问题似乎是问你是否可以通过编程方式获取它——可能可以通过管理 I/F 获取一些信息。编辑添加:其中一些可以通过 MemoryMXBean 获得,但不是 GC 时间的细节。对不起...
A first step is to use verbosegc:
java -verbose:gc -XX:+PrintGCDetails
, which will give you some information about (wall clock) time consumed in GC operations, and the type of operation (full or incremental). Your question seems to be asking whether you can get it programmatically -- probably can get some info via the management I/F.Edited to add: Some of this is available via the MemoryMXBean, but not the specifics of GC time. Sorry...