jstack 是JDK自带的堆栈跟踪工具,作用有两个: 为Java 进程或者核心文件打印出线程的堆栈信息; 远程调试服务器。 查看用法: jstack -help Usage: jstack [-l] <pid> (to connect to running process) jstack -F [-m] [-l] <pid> (to connect to a hung p......
1. 现象 应用刚上线时发现Java进程占用了大量的CPU份额,但过了几分钟后会降下来(流量没变的情况下),因为已经做了负载均衡,于是拿一台实例重新部署代码上线来分析。具体分析步骤参考另外一篇文章《jstack: Java占用高CPU分析之- GC task thread》。这里简单说一下步骤,重点是分析结果后的解决方法,不过强调一点:当发...
然后我们通过16进制的线程号670b,在threadstack.txt文件中搜索,可以搜到对应的线程(内容太多了,只贴了一小部分):可以看到 at com.wkp.jvm.chapter2.CpuController.loop(CpuController.java:21),第21行就对应我们的while(true)死循环,这样就找到了CPU飙高的原因了。 ? 1 2 3 4 5 6 7 8 9 10 11 12 13...
根据进程ID,找到该进程内最耗费CPU的线程: top -Hp pid 将十进制的线程 ID,转换为十六进制的线程 ID printf(‘%x\n’, thread_id) 使用jstack 查看该线程 ID 的堆栈信息: jstack pid | grep thread_id 当然还可以输出更为详尽的信息:jstack pid | grep -A 10 thread_id 2. JVM GC 堆 Java 中的堆...
1. 现象 应用刚上线时发现Java进程占用了大量的CPU份额,但过了几分钟后会降下来(流量没变的情况下),因为已经做了负载均衡,于是拿一台实例重新部署代码上线来分析。具体分析步骤参考另外一篇文章《jstack: Java占用高CPU分析之- GC task thread》。这里简单说一下步骤,重点是分析结果后的解决方法,不过强调一点:当发...
步骤4: 分析jstack输出中的 GC 信息 在jstack输出中,寻找与 GC 相关的信息。在输出中,你可能会看到如下格式的内容: "Reference Handler" #2 daemon prio=10 os_prio=0 tid=0x00007f8bc4008000 nid=0x3c04 waiting for 0x0000000200000000 java.lang.Thread.State: RUNNABLE ...
如果是 Full GC 次数过多,那么通过 jstack 得到的线程信息会是类似于 VM Thread 之类的线程。 如下是一个代码中有比较耗时的计算,导致 CPU 过高的线程信息: 这里可以看到,在请求 UserController 的时候,由于该 Controller 进行了一个比较耗时的调用,导致该线程的 CPU 一直处于 100%。
at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:413) "VM Thread" prio=10 tid=0x099fc400 nid=0x4f31 runnable "GC task thread#0 (ParallelGC)" prio=10 tid=0x0991f400 nid=0x4f2d runnable "GC task thread#1 (ParallelGC)" prio=10 tid=0x09920400 nid=0x4f2e runnable ...
Loaded:加载class的数量 Bytes:所占用空间大小 Unloaded:未加载数量 Bytes:未加载占用空间 Time:时间 2>编译统计 命令: jstat -compiler 19570 结果: 解析: Compiled:编译数量。 Failed:失败数量 Invalid:不可用数量 Time:时间 FailedType:失败类型 FailedMethod:失败的方法 3>垃圾回收统计 命令: jstat -gc 19570...
得到进程ID为21711,第二步找出该进程内最耗费CPU的线程,可以使用ps -Lfp pid或者ps -mp pid -o THREAD, tid, time或者top -Hp pid,我这里用第三个,输出如下: TIME列就是各个Java线程耗费的CPU时间,CPU时间最长的是线程ID为21742的线程,用 ?