Java调试--线上问题排查--方法/方案/如何

逃离我推掉我的手 2022-11-12 05:22 319阅读 0赞

原文网址：[Java调试--线上问题排查--方法/方案/如何\_IT利刃出鞘的博客-CSDN博客][Java_--_--_IT_-CSDN]

# 其他网址 #

[Java 线上问题排查思路与工具使用\_技术杂谈-CSDN博客][Java _-CSDN]

[java：线上问题排查常用手段\_weixin\_34146410的博客-CSDN博客][java_weixin_34146410_-CSDN]  
[java线上服务问题排查\_and1kaney的专栏-CSDN博客][java_and1kaney_-CSDN]

# 简介 #

**如何得知线上出问题了？**

> 线上出问题时，我们需要进行详细排查，一般情况下，有以下场景我们可以得知线上出问题了：
> 
> 1.  请求很慢或者请求失败
> 2.  监控系统的邮件或者短信提醒

**线上排查步骤**

> **请求很慢或者请求失败**（以下按顺序进行）
> 
> 1.  是否CPU占用过高
> 2.  是否内存占用过高
> 3.  是否磁盘占用过高
> 4.  是否网络故障
> 5.  查看后台日志
> 6.  是否是数据库问题（比如：索引失效、死锁）
> 7.  是否是垃圾回收导致
> 8.  是否死锁等

> **监控系统的邮件或者短信提醒**
> 
>  *  监控系统一般有多种功能，在多种异常情况会报警，如：频繁full gc。
>  *  如果是具体的异常（如：频繁full gc）则直接按对应的项排查即可。若是请求慢之类的，排查方法和上边一样的。

# CPU占用过高 #

**其他网址**

> [线上服务器CPU占用率高如何排查定位问题？\_u011277123的博客-CSDN博客][CPU_u011277123_-CSDN]  
> [性能优化之CPU占用率高（一）\_一直Tom猫的博客-CSDN博客][CPU_Tom_-CSDN]  
> [线上java程序CPU占用过高问题排查\_Vioao's Blog-CSDN博客][java_CPU_Vioao_s Blog-CSDN]

**什么场景需要排查CPU占用？**

> 1.  访问接口的响应速度很慢。
> 2.  系统崩溃无响应
> 3.  压测时要查看CPU、内存、load、rt、qps等指标

**步骤简述**

> 1.  定位进程 （命令：top）
> 2.  定位线程 （命令：top -Hp 进程号）
> 3.  定位代码位置 （命令：jstack）

**排查方法详述**

> 1.  找到占CPU最高的进程。
>     
>     1.  top命令，记下进程号（PID）。假设最高的是：1893
> 2.  通过进程找到对应的线程。
>     
>     1.  top -Hp 1893。假设最高的是：4519
>     2.  （因为Java是单进程多线程的）
> 3.  通过线程定位到代码大概的位置信息。
>     
>     1.  printf %x 4519。结果为：11a7
>     2.  jstack 1893 | grep 11a7 -A 30 --color  
>         结果大概是这样的：
>         
>         ![85560f4e5190e0d3bcfc5ac13e65ab56.png][]

**可能导致CPU使用率飙升的操作**

> 1.  无限循环的while会导致CPU使用率飙升
> 2.  经常使用Young GC会导致CPU占用率飙升
> 3.  频繁的GC。  
>     如果访问量很高，可能会导致频繁的GC甚至Full GC。当调用量很大时，内存分配将如此之快以至于GC线程将连续执行，这将导致CPU飙升。
> 4.  序列化和反序列化。稍后将给出一个示例：当程序执行xml解析时，调用量会增加，从而导致CPU变满。
> 5.  正则表达式。 我遇到了正则表达式使CPU充满的情况; 原因可能是Java正则表达式使用的引擎实现是NFA自动机，它将在字符匹配期间执行回溯。我写了一篇文章“ 正则表达式中的隐藏陷阱 ”来详细解释原因。
> 6.  线程上下文切换。  
>     有许多已启动的线程，这些线程的状态在Blocked（锁定等待，IO等待等）和Running之间发生变化。当锁争用激烈时，这种情况很容易发生。

# 内存占用过高 #

**其他网址**

> [Java应用问题定位系列——内存占用过高 - SegmentFault 思否][Java_ - SegmentFault]  
> [Java 服务内存占用过高的一次排查过程\_谈谈1974-CSDN博客\_java服务内存占用过高][Java _1974-CSDN_java]  
> [java内存占用过高或者cpu占用过高解决\_败毒的博客-CSDN博客][java_cpu_-CSDN]

**步骤简述**

> 定位Java程序内存使用过高或者内存泄漏的问题跟CPU也类似，可分为以下步骤：
> 
> 1.  定位进程 （命令：top）
> 2.  定位线程 （命令：top -Hp 进程号）
> 3.  定位代码位置 （命令：jmap生成快照，**MAT** / **jprofiler** / VisualVM / jhat 查看快照数据）

**1.定位进程**

> 1.  top
> 2.  按下M（按内存占用由大到小排序）
>     
>     1.  // 假设定位到的进程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 Mem
>     
>       PID 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
> 
> 注意观察两点：
> 
> 1.  线程的数量
>     
>     1.  可以看到，它线程数是54（左上角的Threads项），属于正常。
>     2.  若比较大（比如大于1000），要考虑是不是代码有问题：
>         
>         1.  是不是代码里手动起了多个线程。比如：使用OkHttpClient时每次都创建了连接池（ConnectionPool）；应该是只创建一个连接池的。
>         2.  是不是自己创建的线程池最大个数太大了。
> 2.  占内存大的线程的PID
>     
>     1.  如果线程数量正常，就要dump内存的快照信息来查看。

**3.定位代码位置**

> 如果是线上环境，注意dump之前必须先将流量切走，否则大内存dump是直接卡死服务。
> 
> dump当前快照：jmap -dump:format=b,file=dump.hprof 14279
> 
> 查找实例数比较多的业务相关的实例，然后找到相应代码查看。（使用工具查看dump.hprof。比如：MAT、VisualVM、jhat）

# 磁盘问题 #

**步骤简介**

> 1.  是否磁盘快用完了（命令：**df**、du）
> 2.  TPS是否正常（命令：**iostat**、vmstat、lsof）

**1.磁盘快用尽**

> df、du 查看磁盘使用情况。见：[Linux命令--文件系统命令 - feiying0canglang的博客 - CSDN博客][Linux_--_ - feiying0canglang_ - CSDN]

**2.TPS**

> iostat查看tps。见：[Linux命令--监管命令--综合\_feiying0canglang的博客 - CSDN博客][Linux_--_--_feiying0canglang_ - CSDN]

# 网络问题 #

dstat或者netstat

dstat -n

netstat

# 垃圾回收 #

**其他网址**

> [线上FullGC排查思路/实战/解决方案\_Slayer\_Zhao的博客-CSDN博客][FullGC_Slayer_Zhao_-CSDN]  
> [GC原理介绍、排查FGC及线上故障的步骤\_Hello World-CSDN博客][GC_FGC_Hello World-CSDN]

**什么情况下，GC会对程序产生影响？**

> 不管Minor GC还是FGC，都会造成一定程度的程序卡顿（即Stop The World：GC线程开始工作，其他工作线程被挂起），即使采用ParNew、CMS或者G1这些更先进的垃圾回收算法，也只是在减少卡顿时间，而并不能完全消除卡顿。
> 
> 那到底什么情况下，GC会对程序产生影响呢？根据严重程度从高到底，包括以下4种情况：
> 
> 1.  FGC过于频繁
>     
>     1.  FGC通常比较慢，少则几百毫秒，多则几秒，正常情况FGC每隔几个小时甚至几天才执行一次，对系统的影响还能接受。
>     2.  一旦出现FGC频繁（比如几十分钟执行一次），是存在问题的，会导致工作线程频繁被停止，让系统看起来一直有卡顿现象，也会使得程序的整体性能变差。
> 2.  YGC耗时过长
>     
>     1.  一般来说，YGC的总耗时在几十或者上百毫秒是比较正常的，虽然会引起系统卡顿几毫秒或者几十毫秒，这种情况几乎对用户无感知，对程序的影响可以忽略不计。
>     2.  如果YGC耗时达到了1秒甚至几秒（都快赶上FGC的耗时了），那卡顿时间就会增大，加上YGC本身比较频繁，就会导致比较多的服务超时问题。
> 3.  FGC耗时过长
>     
>     1.  FGC耗时增加，卡顿时间也会随之增加，尤其对于高并发服务，可能导致FGC期间比较多的超时问题，可用性降低，这种也需要关注。
> 4.  YGC过于频繁
>     
>     1.  即使YGC不会引起服务超时，但是YGC过于频繁也会降低服务的整体性能，对于高并发服务也是需要关注的。
> 
> 其中，「**FGC过于频繁**」和「**YGC耗时过长**」，这两种情况属于比较典型的GC问题，大概率会对程序的服务质量产生影响。剩余两种情况的严重程度低一些，但是对于高并发或者高可用的程序也需要关注。

**如何排查**

> 1.  公司的监控系统：大部分公司都会有，可全方位监控JVM的各项指标。
> 2.  JDK自带工具：jmap、jstat
>     
>     1.  查看堆内存各区域的使用率以及GC情况：jstat -gcutil pid 1000 （重点关注结果中的YGC、YGCT、FGC、FGCT、GCT）
>     2.  查看堆内存中的存活对象，并按空间排序：jmap -histo pid | head -n20
>     3.  dump堆内存文件：jmap -dump:format=b,file=heap pid
> 3.  第三方工具：MAT、jprofiler

**排查实例**

> [线上FullGC频繁排查-druid\_Rocky的博客-CSDN博客][FullGC_-druid_Rocky_-CSDN]  
> [实际项目中查找频繁FullGC的原因，qq\_38701303的博客-CSDN博客][FullGC_qq_38701303_-CSDN]  
> [一次频繁Full GC的排查过程\_沈鸿斌的博客-CSDN博客\_fullgc排查步骤][Full GC_-CSDN_fullgc]

# 死锁 #

## java死锁 ##

**其他网址**

> [线程中死锁的排查\_moxiaolin的博客-CSDN博客][moxiaolin_-CSDN]  
> [Java死锁排查和Java CPU 100% 排查的步骤整理-CSDN博客\_java oom排查][Java_Java CPU 100_ _-CSDN_java oom]  
> [面试官：如何快速排查死锁？如何避免死锁？][Link 1]

**简介**

> 有三种方法可排查死锁：jps+jstack、jconsole、jvisualvm

**法1：jps+jstack**

**法2：jconsole**

**法3：jvisualvm**

## 数据库死锁 ##

**其他网址**

[Java_--_--_IT_-CSDN]: https://knife.blog.csdn.net/article/details/115105155
[Java _-CSDN]: https://blog.csdn.net/GitChat/article/details/79019454
[java_weixin_34146410_-CSDN]: https://blog.csdn.net/weixin_34146410/article/details/85938385
[java_and1kaney_-CSDN]: https://blog.csdn.net/and1kaney/article/details/51214219#t5
[CPU_u011277123_-CSDN]: https://blog.csdn.net/u011277123/article/details/103495338
[CPU_Tom_-CSDN]: https://blog.csdn.net/weixin_38007185/article/details/107662386
[java_CPU_Vioao_s Blog-CSDN]: https://blog.csdn.net/u010862794/article/details/78020231
[85560f4e5190e0d3bcfc5ac13e65ab56.png]: /images/20221022/eacd46e1794b4fce904fe04102f17d85.png
[Java_ - SegmentFault]: https://segmentfault.com/a/1190000022995307
[Java _1974-CSDN_java]: https://blog.csdn.net/weixin_45505313/article/details/104992561
[java_cpu_-CSDN]: https://blog.csdn.net/Afra_bd/article/details/100857143
[Linux_--_ - feiying0canglang_ - CSDN]: https://blog.csdn.net/feiying0canglang/article/details/90549852
[Linux_--_--_feiying0canglang_ - CSDN]: https://blog.csdn.net/feiying0canglang/article/details/102717503
[FullGC_Slayer_Zhao_-CSDN]: https://blog.csdn.net/qq_38905818/article/details/106326252
[GC_FGC_Hello World-CSDN]: https://blog.csdn.net/weixin_38004638/article/details/106135505
[FullGC_-druid_Rocky_-CSDN]: https://blog.csdn.net/wilsonpeng3/article/details/70064336
[FullGC_qq_38701303_-CSDN]: https://blog.csdn.net/qq_38701303/article/details/106105696
[Full GC_-CSDN_fullgc]: https://blog.csdn.net/u012422829/article/details/78154495
[moxiaolin_-CSDN]: https://blog.csdn.net/qq_37909508/article/details/89675335
[Java_Java CPU 100_ _-CSDN_java oom]: https://blog.csdn.net/u010648555/article/details/80721815
[Link 1]: https://juejin.cn/post/6844904100488806413