问题标签 [thread-dump]

ctrl+break 和 java 程序进行的线程转储有什么区别？
我正在使用下面的代码片段来获取线程转储

映射 st = Thread.getAllStackTraces();

我正在分析进行线程转储的方法之间的差异。以下是我正在研究的几个

1. 定义一个 jmx bean，它在单击声明的 bean 操作时通过 Runtime.exec() 触发 jstack。

2. 守护线程在预定义的时间间隔后重复执行“ManagementFactory.getThreadMXBean().dumpAllThreads(true, true)”。

比较两者之间的线程转储输出，我看到方法 2 的以下缺点

1. 使用方法 2 记录的线程转储无法被 TDA 等开源线程转储分析器解析
2. 输出不包括在分析高 CPU 问题时可能有用的本机线程 ID（对吗？）
3. 还有吗？

我很高兴得到有关的建议/意见

1. 在生产代码中通过 Runtime.exec() 执行 jstack 有什么缺点吗？各种操作系统（windows、linux）上的任何兼容性问题？

2. 还有其他方法来进行线程转储吗？

谢谢你。

编辑 -

1和2的组合方法似乎是要走的路。我们可以在后台运行一个专用线程，并以线程转储分析器可以理解的格式在日志文件中打印线程转储。如果需要任何仅由 jstack 输出记录的额外信息（比如可能是本机线程 id），我们会根据需要手动执行。

我在我的应用程序中对主机进行了线程转储，其中大多数线程都处于(state = IN_NATIVE)状态。

在这些情况下，只有几个线程被阻塞：

和

和

我们做了一些HttpConnections，请求在可配置的时间后超时。当我重新启动主机时，一切恢复正常。

所以，我认为线程应该在某个时候被阻塞。

在 NATIVE 代码中运行的线程指向这里：

我认为这是罪魁祸首。我们在内部使用ImageIO和Jsoup进行这些调用的库。

我对阅读线程转储没有太多想法，而且我是新手。但任何帮助将不胜感激。

是否所有本机运行的线程都可能导致问题？我应该如何进行？

谢谢，

在应用程序线程转储中，我可以看到具有五个线程的线程池，如下所示：

但我不直接使用这样的东西，也没有在依赖项中看到这样的东西。

这是什么（hidden.edu.emory.mathcs.backport）以及为什么使用它（在 jdk 7 上运行的应用程序）？我可以检测到应用程序的哪个部分启动它吗？

最近我遇到了线程阻塞的情况。

线程转储说以下

有大约 200 多个线程在 0x000000069c327028 锁上被阻塞。

PKSyncUtils$PKSyncObject 或其他东西是否可能存在锁定问题。

我有一个 Web 服务器，它有一些请求在重负载下表现不佳。我尝试使用常规的久经考验的技术，但它们存在各种问题。

尝试过的技术

1. Yourkit 中的采样/跟踪分析
   • 我无法在负载下使用分析器，因为只有少数特定请求表现不佳
   • 仅测试单个请求不会重现性能问题
2. 线程转储
   • 我尝试以固定的时间间隔进行线程转储，但是如果时间间隔很大，则很难分辨出实际上慢的是什么，如果时间间隔很短，则会对服务器的性能特性影响太大

当服务器处于负载状态时，如何分析单个请求的性能？

我有以下线程转储（见下文），我不确定我是否有死锁。

有人可以请教吗？

我已经在进程上运行 jstack 并且它没有检测到任何死锁。但是，当我运行我的 web 应用程序时，Tomcat 无限期挂起，并且执行了 9 次以下代码：

如果不是死锁，还能是什么？

我经常使用 Java Thread Dumps 进行事后分析和服务器减速分析。问题是线程转储通常很长，理解线程之间的并发关系可能很乏味。

是否有（最好是在线的）工具可以解析 Java 线程转储并显示可读的摘要？

在拼命尝试任何方法来解决我的负载测试故障时，我遇到了TDA，这是一个用于 Java 的线程转储分析工具。不知何故，我不觉得我在关注它的输出。例如，在有一个 8 个线程被 BLOCKED 的监视器实例的情况下，不应该有一个线程处于 RUNNABLE 状态吗？某些线程必须获得该监视器的锁定才能将其他 8 个线程置于 BLOCKED 状态，是吗？

第二件事 - 关于 TDA 术语 - 有一个类别“线程在监视器上休眠（675 个线程休眠）”和一个称为“线程锁定监视器（806 个线程锁定）”。这两个类别都包含 WAITING、BLOCKED 或 TIMED_WAITING 的线程。我能说的唯一区别是后一类还包含处于 RUNNABLE 状态的线程。它们之间还有其他区别吗？我没有得到的是“睡在监视器上”的句法。

谢谢！

我已经获得了 jvisualvm 为使用 JNI 实现的本机共享库生成的线程转储。它在一个应用程序中运行，该应用程序通过 Dot.Net 的 Parallel.For 从多个线程调用它。库的 java 部分有一个线程池，但它的大小是有限的，并且库的 native 部分本身不创建任何线程。

似乎正在发生的事情是，正在创建越来越多的线程，最终应用程序因内存不足错误而崩溃。奇怪的是，应用程序基本上唯一要做的就是在循环中调用 Parallel.For 中的库，并且由它创建的任何线程都不应该“泄漏”（对吗？）。

线程转储包含许多形式的条目：

这到底是什么意思呢？