标签: thread-dump

我有时不得不从Tomcat服务器查看线程转储.但是,这是一个非常缓慢的过程,因为我的应用程序使用具有几百个线程的线程池.我看到的大多数线程转储包括许多线程的相同堆栈跟踪,因为它们空闲等待工作.

是否有任何工具可以解析线程转储,只显示唯一的堆栈跟踪以及每个状态中线程数的计数？这将允许我快速忽略在公共位置等待工作的数十或数百个线程.

我已经尝试过线程转储分析器,但这并没有对常见的堆栈跟踪进行任何总结.

我有一个无法正常关闭的Tomcat服务器的问题.我在发出shutdown命令后进行了一次线程转储,它看起来像这样:

http://pastebin.com/7SW4wZN9

我认为是不允许VM关闭的"可疑"的线程是名为"pool-4-thread-1"的线程.其余的是守护程序线程或内部VM线程.在试图找出这个线程的用途时,我注意到还有其他java程序可以创建具有相似名称的线程(例如,JVisualVM创建这样的线程).

所以我想知道是否有人知道这个线程是什么以及如何创建它.

是否有任何已知的命令行工具要求JVM查看java程序的内存使用情况和线程转储.像无头的jvisualvm？

有多种方法可以在java中生成线程转储.

我想使用JVMTI(C API)来生成它,以评估其对正在运行的JVM的性能影响.(我知道jstack和JMX;这个问题一般不是关于获取线程转储,而是关于使用JVMTI API).

我的代码是基于这篇博文.在那里,java代理附加到SIGQUIT信号.我想避免这种情况,因为这与JVM用于将线程转储写入stdout的信号相同.我想避免这种两面性.

换句话说,我想要附加一个不同的信号,或者找到一种让代理定期生成线程转储的方法.

客户在Windows 10 Build 1703计算机上看到此错误,我没有得到它

他们用Java 1.8.0_111-b14得到了这个

EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x0000000076fd6adf, pid=3164, tid=0x00000000000027d4

我让他们更新到最新版本1.8.0_131-b11,他们仍然是同样的错误.至少pc部分是同样的错误.

我认为错误是他们的机器特有的,我现在发现了一些类似的问题,但没有解决方案.

https://bugs.openjdk.java.net/browse/JDK-8178846?jql=text%20~%20%22msvcr100.dll%2B0x36adf%22

---------------  S Y S T E M  ---------------

OS: Windows 10.0 , 64 bit Build 15063 (10.0.15063.0)

CPU:total 12 (initial active 12) (6 cores per cpu, 2 threads per core) family 6 model 45 stepping 7, cmov, cx8, fxsr, mmx, sse, sse2, sse3, ssse3, sse4.1, sse4.2, popcnt, avx, aes, clmul, ht, tsc, tscinvbit, tscinv

Memory: 4k page, physical 33488896k(26044808k free), swap 38469632k(28180956k free) …

我喜欢以编程方式生成线程转储.我了解到基本上有两种方法可以做到:

1. 使用"Java虚拟机工具接口"JVM-TI
2. 使用更高抽象的"Java调试器接口"JDI

对于JVM-TI,我能够找到一些有用的信息,但我必须编写一个JNI-DLL,至少暂时我想避免.使用JDI,我可以使用Java,似乎我可以在应用程序中使用它.但我无法找到某种教程或HOWTO.我能找到的唯一文件是Java-Docs http://java.sun.com/j2se/1.5.0/docs/guide/jpda/jdi/,这对我没有帮助,因为它没有给我看如何使用这个类.

那么,有没有人知道我能阅读的好教程/书？

感谢任何帮助!

有一天,我们的Java Web应用程序的CPU使用率达到100%.重启解决了事件但不是问题,因为问题回来几个小时后.我们怀疑新版本引入了无限循环,但我们没有对代码或服务器进行任何更改.

我们设法通过使用kill -QUIT进行多次线程转储以及查看和比较每个线程详细信息来找到问题.我们发现一个线程调用堆栈出现在所有线程转储中.在分析之后,有一个while循环条件,对于在数据库中定期更新的某些数据,它永远不会出错.

对Web应用程序的几个线程转储的分析非常繁琐.

那么您是否知道在生产环境中找到此类问题的更好方法或工具？

你知道一些好的线程转储分析工具吗？完美将是:

• 自由
• 可以读取一些线程转储并进行比较
• 指出哪些线程占用时间最长,线程锁定的类是什么等等.
• 显示线程,锁,死锁和等待获取单个锁的多个线程

编辑:

• 离线分析 - 使用一个或多个线程转储加载文件并对其进行分析.

编辑: 我的选择是:武士.它具有我需要的所有功能:加载日志文件,并比较几个线程转储.分析它并指出:

• 等待线程
• 被阻止的线程
• 阻止线程
• 僵局

我会回答问题,因为TDA是给出的最佳答案.

我习惯于看到如下所示的Java线程转储,这是由Sun HotSpot JVM及其衍生产品(如OpenJDK)生成的:

"main" prio=10 tid=0x00007f4020009000 nid=0x538c in Object.wait() [0x00007f402891f000]
   java.lang.Thread.State: WAITING (on object monitor)
    at java.lang.Object.wait(Native Method)
    - waiting on <0x0000000614ea64e8> (a java.lang.Object)
    at java.lang.Object.wait(Object.java:503)
    at org.eclipse.jetty.util.thread.QueuedThreadPool.join(QueuedThreadPool.java:386)
    - locked <0x0000000614ea64e8> (a java.lang.Object)
    at org.eclipse.jetty.server.Server.join(Server.java:398)
    at org.mortbay.jetty.plugin.AbstractJettyMojo.startJetty(AbstractJettyMojo.java:531)
    at org.mortbay.jetty.plugin.AbstractJettyMojo.execute(AbstractJettyMojo.java:364)
    at org.mortbay.jetty.plugin.JettyRunMojo.execute(JettyRunMojo.java:528)
    at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
    at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)

现在,在协助其他用户使用我的软件时,我偶尔会遇到另一种形式的线程转储,如下所示:

Thread 9255: (state = BLOCKED)
 - sun.reflect.annotation.AnnotationType.getInstance(java.lang.Class) @bci=0, line=63 (Interpreted frame)
 - sun.reflect.annotation.AnnotationParser.parseAnnotation(java.nio.ByteBuffer, sun.reflect.ConstantPool, java.lang.Class, boolean) @bci=94, line=202 (Interpreted frame)
 - sun.reflect.annotation.AnnotationParser.parseAnnotations2(byte[], sun.reflect.ConstantPool, java.lang.Class) @bci=39, line=69 (Compiled frame) …

我有一个应用程序的threaddump,显示3个线程如下.

===============

"http-443-11" daemon prio=10 tid=0x00000000473bc800 nid=0x3590 waiting on condition [0x0000000061818000]
   java.lang.Thread.State: WAITING (parking)
    at sun.misc.Unsafe.park(Native Method)
    - parking to wait for  <0x00000007612a3880> (a java.util.concurrent.Semaphore$NonfairSync)

"http-443-4" daemon prio=10 tid=0x00000000451f6000 nid=0x243a waiting on condition [0x0000000055354000]
   java.lang.Thread.State: WAITING (parking)
    at sun.misc.Unsafe.park(Native Method)
    - parking to wait for  <0x00000007612a3880> (a java.util.concurrent.Semaphore$NonfairSync)

"http-443-7" daemon prio=10 tid=0x000000004602e000 nid=0x2974 waiting on condition [0x000000005e6e7000]
   java.lang.Thread.State: WAITING (parking)
    at sun.misc.Unsafe.park(Native Method)
    - parking to wait for  <0x00000007612a3880> (a java.util.concurrent.Semaphore$NonfairSync)

===============

"等待条件[]"有什么意义？[]中的数字有什么意义？