我使用jstack获取具有最高cpu利用率的PID的线程转储。它指向带有nid 0x4974的线程。
“VM Thread”prio = 10 tid = 0x00007ffc60068800 nid = 0x4974 runnable“VM 周期性任务线程“prio = 10 tid = 0x00007ffc60098000 nid = 0x497b 等待条件JNI全球参考:1182
我在进行分析时遇到了问题,因为它没有线程的状态以及正在执行的代码,这与我在网上看到的示例线程转储不同。是否有任何免费软件可以在线分析.txt
threaddump文件?
感谢那些回复的人。好的,所以我能够学习如何使用武士,tda和ibm线程转储工具。似乎问题在于创建的线程数,等待监视的线程,锁定和阻塞。但我想知道你们是否有额外的投入。这是我从TDA得到的:
当它处于100%cpu利用率时
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%且重置后,我上传了threaddumps。我还包括我使用的工具(武士,tda和ibm线程和监视器转储分析器) http://www.mediafire.com/?901mduvodm97d8v,x72cdixp8fltabu,fhfw4e50c7fzu4t,1oq2npaxmtxz0dq,i0u997fhvxfagd3,cdewe4de6x3rhe4,w2ndwqw2ekwixkd,qsbst5ow6f59p75,9fx8w8qpfdhjmyx,levpqppb3ouh71q
答案 0 :(得分:1)
这些内部线程没有Java线程堆栈,因此没有任何常规工具可以提供帮助。如果这些消耗过多CPU,我会首先怀疑您正在使用的Java版本中存在错误。我会尝试使用Java 6 update 45或Java 7 update 45。
要诊断此问题,您需要本机堆栈转储并充分了解JVM的内部。
答案 1 :(得分:0)
转到IBM Thread and Monitor Dump Analyzer for Java从IBM下载该工具。但是为了您的目的,您可以自己分析线程转储,并在线程堆栈中使用线程堆栈跟踪映射您从jstack找到的ID。获取线程转储:
on Linux: kill -3 pid
on Windows: Ctrl-Break (not Ctrl-C)
之后,您可以从命令窗口或标准输出中复制线程转储。