我使用 jstack 来获取 CPU 利用率最高的 PID 的线程转储。它指向 nid 0x4974 的线程。
"VM Thread" prio=10 tid=0x00007ffc60068800 nid=0x4974 runnable "VM Periodic Task Thread" prio=10 tid=0x00007ffc60098000 nid=0x497b waiting on condition JNI global references: 1182
我在分析过程中遇到了问题,因为它没有线程的状态以及正在执行的代码,这与我在网络上看到的示例线程转储不同。是否有任何免费软件(最好是在线)可以分析 .txt
threaddump 文件?
感谢各位的回复。好的,所以我能够学习如何使用 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% 的线程正在监视器上 hibernate 。
这可能表明它们正在等待某些重载或不可用的外部资源(例如数据库),或者只是等待执行某些操作(空闲线程)。您应该使用过滤器检查 hibernate 线程,排除所有空闲线程。
我们只有大约 60 个客户。
我在 CPU 利用率为 100% 时以及重置后上传了线程转储。我还包括了我使用的工具(samurai、tda 和 ibm 线程和监视器转储分析器) http://www.mediafire.com/?901mduvodm97d8v,x72cdixp8fltabu,fhfw4e50c7fzu4t,1oq2npaxmtxz0dq,i0u997fhvxfagd3,cdewe4de6x3rhe4,w2ndwqw2ekwixkd,qsbst5ow6f59p75,9fx8w8qpfdhjmyx,levpqppb3ouh71q
最佳答案
这些内部线程没有 Java 线程堆栈,因此任何普通工具都无济于事。如果这些消耗过多的 CPU,我首先会怀疑您正在使用的 Java 版本中存在错误。我会尝试使用 Java 6 update 45 或 Java 7 update 45。
要诊断此问题,您需要 native 堆栈转储并充分了解 JVM 的内部结构。
关于java - 100% CPU 利用率需要帮助分析线程转储,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/19762298/