JVM在GC中花费时间时，线程转储是什么样的

Question

在分析Java应用程序时，我注意到一个有趣的事实。当JVM在GC中时，死亡线程转储螺旋状： 通用标签

因此，TIMED_WAITING状态下有很多线程。从理论上讲，这种情况很容易在正常运行的应用程序中找到（应用程序此时根本没有任何传入请求），但是我什至找不到单个请求调度线程做有用的事情（标称命中率约为100 hps）。

这种行为是否与GC无关，或者只是偶然？

Answer 1

仅回答问题的标题：

当JVM在GC中花费时间时，线程转储是什么样的？

答案是：您没有办法（以通常的方式）获得此类转储。

JVM仅在达到 safepoint <后，才处理线程转储请求/ a>在GC中根本无法发生。

但是有一种欺骗方法，可以借助本文中提到的未记录的JVMTI函数AsyncGetCallTrace获得活动GC的线程转储：

http://jeremymanson.blogspot.com/ 2010/07 / why-many-profilers-have-serious.html

它还暗示 Oracle Solaris Studio 可以被使用进行混合的本机/ java线程转储。

Answer 2

尝试使用jmap -histo：随着时间的流逝，您可以比较输出，查看哪些对象类型正在增长。

您需要为jmap安装JDK。 http://docs.oracle.com/javase/6/docs/technotes/tools/share/jmap.html

警告，jmap过于密集，它将在运行时暂停所有线程，仅需几秒钟。进程可以进行核心转储，因为它很密集，通常它既快速又安全，但是我看到它会锁定或杀死大型应用程序，多千兆位堆。

Answer 3

我的猜测是您有一个正在等待执行操作的线程池。如果您的过程高效，并且每秒甚至有100个请求，那么即使是一个线程正在执行某项操作，也可能会遇到麻烦。我建议您查看进程的CPU负载。如果为50％，则有50％的机会找到一个线程（可能不是请求线程）来做某事。

如果要查看服务器花费的时间，我可以尝试使用VisualVM之类的探查器，或诸如YourKit之类的商业探查器。

用Google搜索代码，我发现了一个不同的版本 http://grepcode.com/file/repo1.maven.org/maven2/org.mortbay.jetty/jetty-util/7.0.0.pre5 / org / mortbay / thread / QueuedThreadPool.java 但是我怀疑您的线程在RUND（）方法中是TIMED_WAIT 通用标签