Java问题排查系列--线上问题排查的方法/步骤
原文网址：Java问题排查系列--线上问题排查的方法/步骤_IT利刃出鞘的博客-CSDN博客
简介
本文介绍如何排查Java的线上问题。包括：如何得知线上出问题了，线上排查步骤简述，CPU、内存、磁盘、网络、垃圾回收、死锁的详细排查步骤。
线上问题排查简介
如何得知线上出问题了？
线上出问题时，我们需要进行详细排查，一般情况下，有以下场景我们可以得知线上出问题了：
- 用户反馈功能不能正常使用
- 监控系统的邮件或者短信提醒
线上排查步骤
以下按顺序进行
- 是否CPU占用过高
- 是否内存占用过高
- 是否磁盘占用过高
- 是否网络故障
- 查看后台日志
- 是否是数据库问题（比如：索引失效、死锁）
- 是否是垃圾回收导致
- 是否死锁等
CPU占用过高
什么场景需要排查CPU占用？
- 访问接口的响应速度很慢。
- 系统崩溃无响应
- 压测时要查看CPU、内存、load、rt、qps等指标
步骤简述
- 定位进程 （命令：top）
- 定位线程 （命令：top -Hp 进程号）
- 定位代码位置 （命令：jstack）
排查方法详述
- 找到占CPU最高的进程。
- top命令，记下进程号（PID）。假设最高的是：1893
- 通过进程找到对应的线程。
- top -Hp 1893。假设最高的是：4519
- （因为Java是单进程多线程的）
- 通过线程定位到代码大概的位置信息。
- printf %x 4519。结果为：11a7
- jstack 1893 | grep 11a7 -A 30 --color
结果大概是这样的：
可能导致CPU使用率飙升的操作
- 无限循环的while
- 经常使用Young GC
- 频繁的GC
如果访问量很高，可能会导致频繁的GC甚至Full GC。当调用量很大时，内存分配将如此之快以至于GC线程将连续执行，这将导致CPU飙升。 - 序列化和反序列化
- 稍后将给出一个示例：当程序执行xml解析时，调用量会增加，从而导致CPU变满。
- 正则表达式
- 我遇到了正则表达式使CPU充满的情况; 原因可能是Java正则表达式使用的引擎实现是NFA自动机，它将在字符匹配期间执行回溯。我写了一篇文章“ 正则表达式中的隐藏陷阱 ”来详细解释原因。
- 线程上下文切换。
- 有许多已启动的线程，这些线程的状态在Blocked（锁定等待，IO等待等）和Running之间发生变化。当锁争用激烈时，这种情况很容易发生。
内存占用过高
步骤简述
定位Java程序内存使用过高或者内存泄漏的问题跟CPU也类似，可分为以下步骤：
- 定位进程 （命令：top）
- 定位线程 （命令：top -Hp 进程号）
- 定位代码位置 （命令：jmap生成快照，MAT / jprofiler / VisualVM / jhat 查看快照数据）
1.定位进程
- top
- 按下M（按内存占用由大到小排序）
- // 假设定位到的进程ID为14279。
2.定位线程
top -Hp 14279;
按下M（按内存占用由大到小排序）
top - 18:33:07 up 25 days, 7:48, 1 user, load average: 0.17, 0.27, 0.23
Threads: 54 total, 1 running, 53 sleeping, 0 stopped, 0 zombie
%Cpu(s): 0.5 us, 0.7 sy, 0.0 ni, 98.8 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
KiB Mem : 8168236 total, 231696 free, 3660496 used, 4276044 buff/cache
KiB Swap: 969964 total, 969964 free, 0 used. 4197860 avail MemPID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
14293 weiping 20 0 4508772 97036 18112 S 10 12 152:35.42 java
14279 weiping 20 0 4508772 97036 18112 S 5.0 1.2 0:00.00 java
14282 weiping 20 0 4508772 97036 18112 S 0.0 1.2 0:00.37 java注意观察两点：
- 线程的数量
- 可以看到，它线程数是54（左上角的Threads项），属于正常。
- 若比较大（比如大于1000），要考虑是不是代码有问题：
- 是不是代码里手动起了多个线程。比如：使用OkHttpClient时每次都创建了连接池（ConnectionPool）；应该是只创建一个连接池的。
- 是不是自己创建的线程池最大个数太大了。
- 占内存大的线程的PID
- 如果线程数量正常，就要dump内存的快照信息来查看。
3.定位代码位置
如果是线上环境，注意dump之前必须先将流量切走，否则大内存dump是直接卡死服务。
dump当前快照：jmap -dump:format=b,file=dump.hprof 14279
查找实例数比较多的业务相关的实例，然后找到相应代码查看。（使用工具查看dump.hprof。比如：MAT、VisualVM、jhat）
磁盘问题
步骤简介
- 是否磁盘快用完了（命令：df、du）
- TPS是否正常（命令：iostat、vmstat、lsof）
1. 磁盘快用尽
df、du 查看磁盘使用情况。见：Linux命令--查看磁盘--df/du--使用/教程/示例_IT利刃出鞘的博客-CSDN博客
2. TPS
iostat查看tps。见：Linux命令--统计磁盘与CPU--iostat--使用/教程/实例_IT利刃出鞘的博客-CSDN博客
网络问题
dstat或者netstat
dstat -n
netstat
垃圾回收
什么情况下，GC会对程序产生影响？
不管Minor GC还是FGC，都会造成一定程度的程序卡顿（即Stop The World：GC线程开始工作，其他工作线程被挂起），即使采用ParNew、CMS或者G1这些更先进的垃圾回收算法，也只是在减少卡顿时间，而并不能完全消除卡顿。
那到底什么情况下，GC会对程序产生影响呢？根据严重程度从高到底，包括以下4种情况：
- FGC过于频繁
- FGC通常比较慢，少则几百毫秒，多则几秒，正常情况FGC每隔几个小时甚至几天才执行一次，对系统的影响还能接受。
- 一旦出现FGC频繁（比如几十分钟执行一次），是存在问题的，会导致工作线程频繁被停止，让系统看起来一直有卡顿现象，也会使得程序的整体性能变差。
- YGC耗时过长
- 一般来说，YGC的总耗时在几十或者上百毫秒是比较正常的，虽然会引起系统卡顿几毫秒或者几十毫秒，这种情况几乎对用户无感知，对程序的影响可以忽略不计。
- 如果YGC耗时达到了1秒甚至几秒（都快赶上FGC的耗时了），那卡顿时间就会增大，加上YGC本身比较频繁，就会导致比较多的服务超时问题。
- FGC耗时过长
- FGC耗时增加，卡顿时间也会随之增加，尤其对于高并发服务，可能导致FGC期间比较多的超时问题，可用性降低，这种也需要关注。
- YGC过于频繁
- 即使YGC不会引起服务超时，但是YGC过于频繁也会降低服务的整体性能，对于高并发服务也是需要关注的。
其中，「FGC过于频繁」和「YGC耗时过长」，这两种情况属于比较典型的GC问题，大概率会对程序的服务质量产生影响。剩余两种情况的严重程度低一些，但是对于高并发或者高可用的程序也需要关注。
如何排查
- 公司的监控系统：大部分公司都会有，可全方位监控JVM的各项指标。
- JDK自带工具：jmap、jstat
查看堆内存各区域的使用率以及GC情况：jstat -gcutil pid 1000 （重点关注结果中的YGC、YGCT、FGC、FGCT、GCT）
查看堆内存中的存活对象，并按空间排序：jmap -histo pid | head -n20
dump堆内存文件：jmap -dump:format=b,file=heap pid
- 第三方工具：MAT、jprofiler
排查实例
线上FullGC频繁排查-druid_Rocky的博客-CSDN博客
实际项目中查找频繁FullGC的原因，qq_38701303的博客-CSDN博客
一次频繁Full GC的排查过程_沈鸿斌的博客-CSDN博客_fullgc排查步骤
Java问题排查系列--线上问题排查的方法/步骤相关推荐
- 【面试篇】Java自带的线上问题排查工具
[面试篇]Java自带的线上问题排查工具 (1)jps命令 来查看虚拟机进程状态工具 jps是Java提供的一个显示当前所有Java进程的pid的命令,适合查看当前Java进程的一些简单情况.类似于p ...
- Java线上问题排查系列--后端接口响应慢的排查方法及解决方案
原文网址:Java线上问题排查系列--后端接口响应慢的排查方法及解决方案_IT利刃出鞘的博客-CSDN博客 简介 说明 本文介绍Java后端接口响应慢的排查的方法以及如何解决. 如何发现接口响应慢了? ...
- linux 内存溢出排查_记一次JAVA 线上故障排查完整套路
JAVA线上故障排查全套路 线上故障主要会包括cpu.磁盘.内存以及网络问题,而大多数故障可能会包含不止一个层面的问题,所以进行排查时候尽量四个方面依次排查一遍.同时例如jstack.jmap等工具也 ...
- 【深入理解JVM】JAVA线上故障排查全套路
线上故障主要会包括cpu.磁盘.内存以及网络问题,而大多数故障可能会包含不止一个层面的问题,所以进行排查时候尽量四个方面依次排查一遍.同时例如jstack.jmap等工具也是不囿于一个方面的问题的,基 ...
- Java线上问题排查思路及Linux常用问题分析命令学习
前言 之前线上有过一两次OOM的问题,但是每次定位问题都有点手足无措的感觉,刚好利用星期天,以测试环境为模版来学习一下Linux常用的几个排查问题的命令. 也可以帮助自己在以后的工作中快速的排查线上问 ...
- Java 线上问题排查思路与工具使用
本文来自作者 蓬蒿 在 GitChat 上分享 「Java 线上问题排查思路与工具使用」,「阅读原文」查看交流实录. 「文末高能」 编辑 | 哈比 一.前言 Java 语言是当前互联网应用最为广泛的语 ...
- JAVA线上问题排查及常用命令
前言 线上问题排查是程序员绕不开路.线上故障主要会包括 CPU.磁盘.内存以及网络问题,而大多数故障可能会包含不止一个层面的问题,所以进行排查时候尽量四个方面依次排查一遍.同时例如 jstack.jm ...
- java线程堆栈nid.tid_java排查一个线上死循环cpu暴涨的过程分析
问题,打一个页面cpu暴涨,打开一次就涨100%,一会系统就卡的不行了. 排查方法,因为是线上的linux,没有用jvm监控工具rim链接上去. 只好用命令排查: top cpu排序,一个java进程 ...
- java基础巩固-宇宙第一AiYWM：为了维持生计，做项目经验之~SSM项目错误集锦Part3（项目蹦+pg数据库坏+100%--＞线上故障排查经验【业务bug第一步一定是先看日志，写好日志】）~整起
项目中遇到的一个问题:项目忽然蹦了,用我们的域名登陆不上去了. 根据之前的经验,一般比如我们项目登不上去了或者数据库不上数据了(数据不更新),直接在Xshell上远程reboot一下,再重启一下tom ...
- 全面Java程序线上故障排查
文章内容过长,望读者见谅,小编在文末准备了彩蛋 目录 这篇文章是在公司做了不少的线上Java服务故障排查和优化之后的一个总结,可以作为一个工具清单,在分析问题的时候需要有整体思路:全局观,先从系统层面 ...
最新文章
- R2LIVE: 一个鲁棒实时的雷达-惯导-视觉紧耦合的位姿估计和建图系统
- 【RocketMQ工作原理】消息堆积与消费延迟
- No.6 建立swap分区、进程、安装软件包的方法(rpm,yum,编译)
- 阿里mysql同步工具otter的docker镜像
- 30秒内便能学会的30个超实用Python代码片段
- HDU - 1160 FatMouse's Speed(最长不下降子序列)
- dev 报表设计器 怎么设置每页10行_可嵌入您系统的.NET 报表控件ActiveReports：带状列表组件...
- C语言自学《三》---- 条件判断
- 米粉期盼小米Civi推Pro版本：搭载骁龙870旗舰芯片
- hibernate分页中跳转到第几页的功能
- windows10资讯和兴趣怎么关闭？
- FOR XML PATH 应用及其反向分解
- Vue 下载本地静态资源static文件夹
- 公共场合的wifi 靠不住
- 字符串按照ASCII排序
- Python地学分析 — GDAL通过矢量裁剪遥感图像
- 帝国cms7.2通过数据库修改用户密码
- 读书笔记：无人机控制（二）
- 真无线降噪蓝牙耳机推荐，综合性能表现不错的降噪蓝牙耳机分享
- 初识数据结构——“数据结构与算法”