jstack实战点睛

状况

在线上不限调试环境可以打断点进行逐步调试,所以就像是黑盒子,总是满脑子无奈的没有一点办法。总想探个究竟,但是没有信息,什么也看不到。

这里吐槽下一下ios和android前端开发的朋友,他们总是厌倦使用debug调试,而是像写js脚本的h5工程师似的,只使用log.info(“1”)、log.info(“2”)、log.info(“3”),这种信息量很小的调试方式。而且觉得debug很麻烦,只能说且行且珍惜。

不论调试,或是解决问题,解决的好坏,解决的速度,很大程度取决于获取到的信息量的多少。

jstack用法

jstack用法很简单一个命令就可以了

jastack <pid> > jstack.log

jstack查看耗时最大的线程

一般发生在系统cpu飙高的情况下,步骤大致如下:
1.top命令查看耗时最大的进程;
2.ps命令查看耗时最大的进程;
3.线程id,转换成16进制数;
4.jstack打印线程栈,查看对应的线程在做什么事情;

jstack查看系统请求卡在了哪个方法

一般发生在我们的某个请求特别慢的情况下,需要查看到底在什么位置卡住了,常见的是在连接db、nosql、zk、redis等的位置发生。

做法也很简单,仍然是jstack打印线程栈,然后查看WAITING的线程,重点查看包含自己代码行的方法调用栈。

问题90%以上是出在自己的代码上的,当然也不排除第三方库的可能性,比如mongodb连接不上的时候就会导致cpu飙高。

mongo连接不上导致cpu飙高

情况是线上的服务器gc特别频繁,cpu使用率很高。我们首先查看的是gc频繁问题,这种问题一般是存在内存的对象的频繁创建,导致内存溢出。

通过MAT工具对jmap获取到的内存栈进行分析,比较容易找到可疑的对象,比如这张图:

这里写图片描述

最大的可疑对象就是mongo,所以我们应该从mongo相关的逻辑下手找问题。

通过进一步的jstack打印线程栈,会发现mongo一直运行在建立连接的位置,如下图:

这里写图片描述

那么接下来的事情就是,确认哪一个mongo的地址连接不上了,问题也就能够迎刃而解。

这个问题,你可能会想为什么没有看日志,解决问题第一的第一就是看日志啊!!为什么没有从日志找到答案,而是绕了这么大的圈子呢?实际上这是mongo的一个经典问题,当连接不上的时候,他不认为是一个要阻断系统的致命问题,所以没有做为严重的异常抛出,必须打开debug日志级别才能看到相关的异常日志。

接口请求等待时间超级长,几乎在不响应状态

对于调试环境,我们打断点就很容易定位问题了,但是如果在线上,不是在调试环境呢?这时候就是各种linux命令工具大显身手的时候了!

当遇到这种情况,第一就是打印线程栈,实在定位不了在增加log输出。

这里看一个线程栈可以定位的场景:

这里写图片描述

已标记关键词 清除标记
相关推荐
©️2020 CSDN 皮肤主题: 撸撸猫 设计师:C马雯娟 返回首页