Java 问题排查技术分享
常见问题 发布者:ou3377 2021-12-16 17:08 访问量:177
直接放PPT截图吧,现在看来依然不过时
可从三个方面入手
知识有很多方面,这里简单列举一下:
举个例子,我们需要理解 Java 对象从申请到被回收整个过程,这个图非常清晰,建议烂熟于心:
然后也要了解常见的垃圾收集器:
吞吐量=单位时间内处理的请求数量=运行代码时间 / (运行代码时间 + 垃圾回收时间)
以 ParNew + CMS 为例 ,尝试回答如下几个问题:
如果我们了解上述的这些知识后,举个实际例子,当我们发现 Young GC 频繁触发,耗时高,该如何优化?
首先思考,Young GC 什么时候触发?答案是 Eden 区不足。
接着,Young GC 耗时主要是哪里耗时?答案是扫描 + 复制,扫描通常很快,复制比较慢。
那我们对症下药,增加新生代大小试试,结果真的解决问题了,为什么?我们也分析一下
新生代大小为 M 时,假设对象存活 750ms,young GC间隔 500ms,扫描时间为 T1,复制时间为 T2
由于T2远远大于T1,所以2T1 < T1 + T2
这就是知识的力量~
Java 栈中的工具,也分为这几类:
这些工具的原理,我们也需要稍微了解下,比如 Cpu profiler大概有两类:
比如 uber 开源的 uber-common/jvm-profiler,它就是基于采样的 Cpu profiler,缺点就是存在 SafePoint Bias 问题,比如有一次排查一个 Cpu 占用问题,就采集到了这样的火焰图,可以看到几乎没啥用
SafePoint(安全点) 可以简单理解为 JVM 可以停顿下来的特定位置的点,如果采样的位置是特定的点,那么采样就不具有代表性,因为可能在非 SafePoint 时可能消耗了更多的 Cpu,这种现象就被称为 SafePoint Bias 问题。
但我用另一个 jvm-profiling-tools/async-profiler 来采集,就能看到性能瓶颈:
虽然 Async-profiler 也是基于采样做,但它能避免 SafePoint Bias 问题,原因是它采用了 AsyncGetCallTrace 的黑科技。于是依据 Async-profiler 给出的火焰图进行优化,Qps 从 58k 涨到 81k,Cpu 反而从72%下降到了41%
数据包括:
这部分就按实际来分析,没有统一模板可言。
说了这么多,从经验角度总结了如下常见问题该从哪些方面入手:
先踢掉故障机器,保留现场再排查问题,根据日志,定位为内存泄漏
小思考:能通过日志直接确定是哪里内存泄露吗?— 答案:不能
具体定位可dump内存下载到本地分析,文件如果太大,可以先压缩下
jmap -dump:format=b,file=/cobar.bin ${pid}
使用 eclipse 的插件 MAT 分析,过程就不放了,结果是发现了一个我们对 Cobar 自定义修改导致的 Bug,如果对内存分析感兴趣,可以直接看我这几篇实战文章:
使用 Arthas trace 跟踪调用
trace com.beibei.airborne.embed.extension.PojoUtils generalize
接入限流降级利器 Sentinel 后,配置一条规则,触发后导致应用僵死,可使用 jstack 进行排查,一眼就看出问题所在
jstack ${pid} > jstack.txt
关键字: java问题排查
文章连接: https://chenzhankj.com/cjwt/824.html
版权声明:文章由 晨展科技 整理收集,来源于互联网或者用户投稿,如有侵权,请联系我们,我们会立即删除。如转载请保留