问题标签 [thread-dump]

我们在单个物理主机上运行多个应用程序实例（每个 tomcat 服务器一个）。应用程序做体面的日志记录。最近我们观察到一些应用程序变慢或挂起，需要重新启动。在线程转储中，发现所有线程在日志语句上都被 BLOCKED，等待锁定println对象。和其他一些对象已经锁定println。但我不明白为什么其他线程没有释放println对象上的锁？我粘贴了一些线程转储快照：

阻塞的线程转储：

记录 println 的线程的线程转储。

我使用 jstack 来获取 CPU 利用率最高的 PID 的线程转储。它指向 nid 为 0x4974 的线程。

“VM 线程”prio=10 tid=0x00007ffc60068800 nid=0x4974 可运行“VM 定期任务线程”prio=10 tid=0x00007ffc60098000 nid=0x497b 等待条件 JNI 全局引用：1182

我在进行分析时遇到问题，因为它没有线程的状态以及正在执行的代码，这与我在网上看到的示例线程转储不同。是否有任何可以分析.txt线程转储文件的最好在线免费软件？

感谢那些回复的人。好的，所以我能够学习如何使用 samurai、tda 和 ibm 线程转储工具。似乎问题在于正在创建的线程数、等待监视器的线程、锁定和阻塞。但我想知道你们是否有额外的投入。这是我从 TDA 得到的：

当它处于 100% cpu 利用率时

我重置后

40% 的线程在监视器上休眠。

这可能表明他们正在等待一些过载或不可用的外部资源（例如数据库），或者只是在等待做某事（空闲线程）。您应该使用排除所有空闲线程的过滤器检查睡眠线程。

我们只有大约 60 个客户。

我在 cpu 利用率为 100% 且重置后上传了线程转储。I also included the tools that i used (samurai,tda,and ibm thread and monitor dump analyzer) http://www.mediafire.com/?901mduvodm97d8v,x72cdixp8fltabu,fhfw4e50c7fzu4t,1oq2npaxmtxz0dq,i0u997fhvxfagd3,cdewe4de6x3rhe4,w2ndwqw2ekwixkd,qsbst5ow6f59p75,9fx8w8qpfdhjmyx, levpqppb3ouh71q

我有一个应用程序的线程转储，它显示了如下所示的 3 个线程。

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

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

“等待条件[]”的意义是什么？[]中的数字是什么意思？

我通过使用 jmap 得到了堆转储。我将它加载到 Eclipse MAT 中。java.lang.Thread 是最大的消费者。当我单击直接支配者时，它会显示一个 ArrayList，其中包含 17K 个对象（org.jboss.security.SecurityAssociation$SubjectContext）。

我在不同的时间（2 小时间隔）进行了堆转储。

java.lang.Thread @ 0xd09f05d0 pool-7-thread-1 线程 112 | 12,198,024 | 7.64%

java.lang.Thread @ 0xd09e64c8 pool-7-thread-1 线程 112 | 19,037,464 | 8.58%

浅堆：112 保留堆：19,037,464 百分比 8.58

堆大小正在增加。

线程对象（0xd09f05d0 ,0xd09e64c8）不同，线程名称相同（pool-7-thread-1）。它是否仍然引用同一个线程并且它的堆在增长？或者一个线程（0xd09f05d0）完成了它的操作并且具有不同对象（0xd09e64c8）的同一个线程用于不同的操作并且它持有不同的对象？

这类似于Java thread dump: BLOCKED thread without "waiting to lock ..."。

基本上，我看到了一个 BLOCKED 线程，但它有它正在等待的锁：

我希望看到- waiting to lock <0x0000000742444ad0>...而不是- locked.... 另一个问题表明垃圾收集是原因，但如果是这种情况，不是所有线程都被阻塞吗？还有其他可运行的线程。另外，我怎么证明是这样的呢？为什么这是观察到的行为？我不想盲目地假设它是垃圾收集器，但几天后才发现它是别的东西。

==辅助信息==

虽然我认为它与手头的问题无关，但这是上面转储的代码部分。

显然，需要在该行上获得一个锁。然而，当一个线程在这个监视器上真正被阻塞时，线程转储中的输出看起来像（这来自同一个转储）：

我感兴趣的转储部分看起来不同（“锁定”而不是“等待锁定”）。我调试了许多死锁并查看了许多线程转储。我总是看到的是“等待锁定”。我从未见过“锁定”但仍在“等待监视器进入”的线程，我想知道这意味着什么。

我们最近在我们的系统中引入了 Drools，不久之后我们的服务器开始出现异常行为（崩溃或延迟增加），我们分析了线程转储，其中的片段如下所示。此池中的大多数线程都处于阻塞状态。

只是想知道什么是相同的详细原因。我应该做哪些其他配置来防止此类问题。

====使用 JAVA 配置更新

我们正在使用 StatefulKnowledgeSessionpublic StatefulKnowledgeSession getStatefullSession()方法。我们创建这个类的 Spring bean 并注入其他类以使用 drools。

我们正在使用 WAS 7，我们的耳朵就部署在上面。

环境细节

操作系统：AIX 7.1

处理器架构：ppc64

处理器数量：8

Java版本：JRE 1.6.0 AIX ppc64-64 build jvmap6460sr10fp1-20120202_101568 (pap6460sr10fp1-20120321_01(SR10 FP1))

虚拟机版本：VM build 20120202_101568 Just-In-Time(JIT) 编译器开关，Ahead-Of-Time (AOT) 编译器开关，编译器版本：r9_20111107_21307ifx1

垃圾收集器版本：GC - 20120202_AA_CMPRSS

Java 堆信息

最大 Java 堆大小：1024m

初始 Java 堆大小：512m

我尝试使用IBM Thread and Monitor Dump Analyzer 工具分析堆转储。

以下是线程摘要

但我无法分析，这个静态是好还是需要改进？

由于我们在 Parking/Waiting on Condition 中始终有这么多线程（每天使用线程 sump 10 次），有时应用程序需要 4 秒来处理 5 条消息，假设是每秒 5 条消息。

应用程序运行良好并达到每秒 5 条消息的 SLA，但一天中有几次说处理 5 条消息需要 4 秒。

注意：并发处理。

如果我当时试图获得线程转储，就像我在上面分享的一样。

我们的应用程序滞后。

我正在使用jstackutil 获取线程转储。

我进行数据准备并对其进行排序。这就是我所拥有的：

198 个线程被阻塞。

据我了解waiting to lock <0x0000000582e56bc8>，他们都在等待一些带有 ID 的线程0x0000000582e56bc8。奇怪的是我在线程转储输出中找不到这个0x0000000582e56bc8，我找不到他们都在等待什么。

或者它不是真的？这是什么0x0000000582e56bc8？

这是转储的小和平：

所有 198 个其他线程转储都相同

更新 1.@Holder 评论后

更新 2感谢@Holder

据我了解waiting to lock <0x0000000582e56bc8>，意味着线程正在等待0x0000000582e56bc8，这是一个指针。接下来你应该找到- locked <0x0000000582e56bc8>. 你会发现 Thread 锁定了一个对象。然后我查看了堆栈跟踪，最后找到了罪魁祸首。

如果你也有问题com.sun.xml.bind.v2.runtime.reflect.opt.AccessorInjector，看看这个问题。

在我的线程转储中，我发现了以下几行：

如何找到实现或启动 this Threador的类Runnable？

我有以下使用 jstack 获得的线程转储，并且想知道单词旁边的十六进制值runnable显示什么。我已经看到其他地方使用的相同值显示为：

这是否意味着其他线程正在等待该线程？

线程转储