jstack命令和JAVA线上故障排查

我不是女神ヾ 2023-01-19 03:19 66阅读 0赞

一、jstack 命令参数

二、jstack解决问题

1、死循环导致cpu飙高

死循环的例子：https://blog.csdn.net/goldenfish1919/article/details/8755378

步骤：查找进程-》查找线程-》分析threadDump日志-》找出问题代码

a、查看cpu高的java进程

top

b、生成进程下所有线程的栈日志

jstack 1721 > 1712.txt

c、查看进程下哪些线程占用了高的cpu

top -p 1712 -H

d、将十进制pid转换为十六进制的pid

printf “%x” 8247

2037

2、死锁问题定位

**JAVA线上故障排查全套路**  
线上故障主要会包括cpu、磁盘、内存以及网络问题，而大多数故障可能会包含不止一个层面的问题，所以进行排查时候尽量四个方面依次排查一遍。同时例如jstack、jmap等工具也是不囿于一个方面的问题的，基本上出问题就是df、free、top 三连，然后依次jstack、jmap伺候，具体问题具体分析即可。

CPU  
一般来讲我们首先会排查cpu方面的问题。cpu异常往往还是比较好定位的。原因包括业务逻辑问题(死循环)、频繁gc以及上下文切换过多。而最常见的往往是业务逻辑(或者框架逻辑)导致的，可以使用jstack来分析对应的堆栈情况。

使用jstack分析cpu问题  
1、先输入top命令找出cpu比较高的进程  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzIyOTI5ODAz_size_16_color_FFFFFF_t_70]  
2、然后使用top -H -p pid，命令找出这个进程里面cpu比较高的线程  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzIyOTI5ODAz_size_16_color_FFFFFF_t_70 1]  
3、然后将占用最高的pid转换为16进制printf ‘%x\\n’ pid得到nid  
![在这里插入图片描述][20210507144937393.png]  
4、使用jstack pid> jstack.log 把对应的进程id输出到指定文件

5、接着直接在jstack中找到相应的堆栈信息jstack pid |grep ‘nid’ -C5  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzIyOTI5ODAz_size_16_color_FFFFFF_t_70 2]  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzIyOTI5ODAz_size_16_color_FFFFFF_t_70 3]  
6、也可以使用cat jstack.log | grep “java.lang.Thread.State” | sort -nr | uniq -c 来观察线程的状态  
\[root@oxyz-dev-app03 ~\]\# cat jstack.log | grep “java.lang.Thread.State” | sort -nr | uniq -c  
124 java.lang.Thread.State: WAITING (parking)  
3 java.lang.Thread.State: WAITING (on object monitor)  
4 java.lang.Thread.State: TIMED\_WAITING (sleeping)  
28 java.lang.Thread.State: TIMED\_WAITING (parking)  
19 java.lang.Thread.State: TIMED\_WAITING (on object monitor)  
27 java.lang.Thread.State: RUNNABLE

7、频繁gc  
当然我们还是会使用jstack来分析问题，但有时候我们可以先确定下gc是不是太频繁，使用jstat -gc pid 1000命令来对gc分代变化情况进行观察，1000表示采样间隔(ms)，S0C/S1C、S0U/S1U、EC/EU、OC/OU、MC/MU分别代表两个Survivor区、Eden区、老年代、元数据区的容量和使用量。YGC/YGT、FGC/FGCT、GCT则代表YoungGc、FullGc的耗时和次数以及总耗时。如果看到gc比较频繁，再针对gc方面做进一步分析，具体可以参考一下gc章节的描述。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzIyOTI5ODAz_size_16_color_FFFFFF_t_70 4]

8、内存溢出，启动的时候增加配置：  
\-Xmx32M -Xms32M -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=./  
注：./指项目根目录  
https://gblfy.blog.csdn.net/article/details/90250602

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzIyOTI5ODAz_size_16_color_FFFFFF_t_70]: /images/20221021/daf28815725e4d069c7946f151c9f887.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzIyOTI5ODAz_size_16_color_FFFFFF_t_70 1]: /images/20221021/03f4b32ecf0241b690abbfe270f35ca4.png
[20210507144937393.png]: /images/20221021/292a55b779054036bc949196f407c283.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzIyOTI5ODAz_size_16_color_FFFFFF_t_70 2]: /images/20221021/a945726d5b5442099c7f9fa785667c89.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzIyOTI5ODAz_size_16_color_FFFFFF_t_70 3]: /images/20221021/7b147549bdb14e9589e12c3f155d0aaf.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzIyOTI5ODAz_size_16_color_FFFFFF_t_70 4]: /images/20221021/a2e573432c5c4f6c8340b858b7382445.png