需要帮助分析Java线程转储

Question

我正在使用武士工具分析线程转储。看起来它有很多被阻塞的线程。我没有从线程转储中获得任何东西的线索。

我在运行在weblogic上的Java应用程序中有一个SQL查询，它需要花费大量时间才能完成。在多次单击我的Java应用程序按钮运行此查询后，我的JVM将挂起。

线程转储可以在@：http://www.megafileupload.com/en/file/379103/biserver2-txt.html中找到

你能帮我理解线程转储是怎么回事吗？

Answer 1

该问题与WLDF将信息记录到日志文件有关。一旦被禁用，它将极大地提高性能。我不喜欢将ThreadLogic作为线程转储分析工具。当你阻塞线程时，不管问题有多复杂，它都会显示循环死锁。

Answer 2

您提供的数据量有点太大了，所以让我们给您一点提示如何继续。为了进行分析，我使用了基于TDA的开源threadlogic应用程序。解析3个MiB的数据需要几秒钟的时间，但在一个文件中很好地显示了22个不同的堆栈跟踪转储：

​

​

深入到揭示真正令人不安的警告和警报列表。

​

​

我没有时间检查所有这些，但这里有一个标记为致命的列表(请记住，假阳性也是可以预期的)：

等待SLSB

描述:正在等待来自无状态会话Bean ( SLSB )空闲池的实例

建议: Beans都在使用中，可用池大小不足

死锁

描述:检测到循环锁依赖导致死锁

建议:在锁中检测到循环依赖的死锁，被阻塞的线程在没有服务器重启的情况下将无法恢复。修复锁定顺序，或尝试在代码级避免锁定或更改锁定顺序，向服务器/产品代码的SR报告

终结器线程被阻止

描述:终结器线程被阻塞

建议:检查Finalizer线程是否因锁而被阻塞，这可能会导致浪费等待从Finalizer队列回收的内存

WLS单播群集不健康

描述:集群成员间单播消息不健康

建议:单播组成员无法正常通信，请应用最新的单播相关补丁并启用消息排序或切换到多播

WLS复用器正在处理服务器请求

描述: WLS复用器正在处理子系统请求

建议: WLS服务器健康是不健康的，因为一些子系统被请求压垮了，这导致Muxer线程直接处理请求。而不是分派到相关子系统。这里可能有一个bug。

卡住的线程

描述:线程卡住，请求需要很长时间才能完成

建议:检查线程或调用耗时过长的原因。是否因为资源不可用、资源不正确或争用Lock而被阻塞？如果它在循环中重复工作，则可以忽略。(就像适配器线程在无限循环中轮询事件)...

Answer 3

线程转储是给定时刻在应用程序中运行的所有线程的快照。线程转储将具有数百/数千个应用程序线程。在每个线程中滚动堆栈跟踪的每一行是很困难的。调用堆栈树将所有线程堆栈跟踪合并到一个树中，并为您提供一个视图。它使得线程转储导航变得更加简单和容易。下面是由fastThread.io生成的示例调用栈树。

​

       Fig 1: Call stack Tree

您可以继续深入查看代码执行路径。图2显示了调用堆栈树图中特定分支的下钻版本。

​

   Fig 2: Drilled down Call Stack Tree

Sample call stack tree generated by FastThread.io