Java 100%cpu利用率需要帮助分析线程转储

我使用jstack获得cpu利用率最高的PID线程转储。它指向具有nid 0x4974的线程

“虚拟机线程”优先级=10 tid=0x00007ffc60068800 nid=0x4974可运行“虚拟机 周期性任务线程“prio=10 tid=0x00007ffc60098000 nid=0x497b 等待条件JNI全局引用：1182

我在分析的过程中遇到了一个问题，因为它没有线程的状态和正在执行的代码，不像我在web上看到的示例线程转储。有没有免费软件可以分析

.txt

线程转储文件

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

当其cpu利用率达到100%时

Overall Thread Count    1001
Overall Monitor Count   644
Number of threads waiting for a monitor  50
Number of threads locking a monitor 636
Number of threads sleeping on a monitor 0
Number of deadlocks 0
Number of Monitors without locking threads 0

在我重置之后

Overall Thread Count  32
Overall Monitor Count  13
Number of threads waiting for a monitor  0
Number of threads locking a monitor  13
Number of threads sleeping on a monitor  13
Number of deadlocks 0
Number of Monitors without locking threads 0

40%的线程在监视器上睡眠

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

我们只有大约60个客户

我在cpu利用率为100%和重置后上传了线程转储。我还包括了我使用的工具（samurai、tda和ibm thread and monitor dump analyzer）

转到从IBM下载该工具。但是出于您的目的，您可以自己分析线程转储，并将从jstack找到的ID映射到线程转储中的线程堆栈跟踪。要获取线程转储，请执行以下操作：

on Linux: kill -3 pid
on Windows: Ctrl-Break (not Ctrl-C)

---

之后，您可以从命令窗口或stdout复制线程转储。

这些内部线程没有Java线程堆栈，因此普通工具都没有帮助。如果这些都消耗了过多的CPU，我首先会怀疑您使用的Java版本中存在错误。我会尝试使用Java6Update45或Java7Update45

---

要诊断此问题，您需要一个本机堆栈转储并充分了解JVM的内部结构。

我将使用visualvm加载线程转储并对其进行分析。您是否可以发布整个线程转储？这将提供更多的线索，说明是什么导致了真正的问题。如果我发布整个线程转储，真的可以吗？它相当长。