jstack实战点睛

Posted 2022-09-24 不去天涯

状况

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

这里吐槽下一下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输出。

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