本文主要是介绍【Java】排障方法论，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
大神文章的总结。整理人: pierre
文章目录
- 一、备份现场
- 1、备份应用日志
- 2、记录问题发生的时间
- 3、备份GC日志
- 4、监控基础资源利用率曲线
- 5、获取堆栈快照信息
- 6、Dump内存信息
- 二、分析问题
- 1、CPU
- 综合CPU利用率高
- 排查思路:
- 优化建议:
- 单核CPU利用率高
- 排查思路:
- 优化建议
- 2、内存
- 频繁FULL GC
- 排查思路:定位无法被回收的对象
- 优化建议
- 内存空间够，依旧触发了Full GC
- 优化建议
- 后台IO高负载造成的长时间JVM GC停顿
- 3、网络
- 超时严重
- 排查思路
- 优化建议
- 发送缓冲区积压
- 排查思路
- 优化建议
- 接收缓冲区积压
- 4、磁盘
- IO Util高
机器异常、代码Bug、业务逻辑不当、开源组件使用姿势不对等等都会造成我们的现网后台服务不稳定，甚至是出现严重的服务挂掉的情况。当面对如此复杂的现网环境时，我们需要有一个清晰的问题排查思路，有章可循方能行之有度。总结一些问题排查的思路。
一、备份现场
- 问题出现的前后几分钟往往比较关键
- 要全:尽可能地把对问题分析有帮助的现场信息都保留备份
- 要快:系统在异常情况下错误日志的输出会更加频繁，可能覆盖掉关键日志
1、备份应用日志
应用日志是最佳切入问题的点:
- 一般系统出现问题时都会有相应的异常日志输出
- 能够定位到具体的代码片段，缩小问题排查范围
2、记录问题发生的时间
所有的信息都能通过时间这个维度刻画
- 问题发生时间点基础资源是否有波动（网卡流量飙升、CPU利用率飙升等）
- 是否存在变更操作，系统是否做过升级
3、备份GC日志
-
JVM的垃圾回收线程优先级高于应用线程
一旦出现频繁FULL GC的情况，应用级别的线程基本处于挂起状态，有时甚至连应用日志也不会输出。
-
长时间的FULL GC就意味着系统无响应，对外表现出来的现象就是超时及不可用
-
判断是否需要进行JVM调优
4、监控基础资源利用率曲线
- 可视化的曲线
- 峰值以及走势
过与前一天或者前一周相同时刻的曲线进行对比，为解决问题提供一个良好的参照
5、获取堆栈快照信息
jstack ${pid}> ${pid}.jstack
- 调用栈上下文
- 线程的状态（是否阻塞、僵死、死锁）信息
这篇关于【Java】排障方法论的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
