# （一）前言 {#一-前言}

再牛逼的程序员都写不出完美无缺的代码，作为后端开发工程师，一不小心就会遇到线上故障。如果线上故障处理不及时，就可能导致各种严重的后果。恰好最近部门出现了一次挺严重但幸运的是影响面不大的线上故障，最后在阿里工作十年的leader分享了线上问题的排查思路。结合这次分享，写下了这篇Java线上问题排查攻略。

# （二）问题发生后的首要工作 {#二-问题发生后的首要工作}

一般来说，线上的问题在发生之前会有一系列的预警，比如CPU被打满，网络达到顶峰等等问题。然后就是客户或者用户的反馈，比如某某页面打不开，系统加载很慢，一直提示报错等等。

这个时候的应急操作是首先记录问题发生时的情况：包括服务器的情况，Java虚拟机的一些情况，数据库的连接情况等等 ，然后尽快让用户能正常使用系统。常用的方法就是系统降级 ：即让出问题的服务先停掉。或者代码回滚 ：往往问题都是在代码更新后出现的。或是重启大法，要尽快的保证用户能正常使用。

# （三）线上问题异常及可能的原因 {#三-线上问题异常及可能的原因}

出现问题时最先需要记录的是线上的各项异常指标。

# 3.1 应用层面 {#_3-1-应用层面}

应用层面的排查主要是CPU、load、内存以及网络

# 3.1.1 CPU {#_3-1-1-cpu}

top命令查看CPU占用情况,基本参数如下:

如果发现CPU占用率很高，这个时候就要考虑CPU跑满的原因：

1、FULL GC 频繁

2、有非常耗CPU的操作

同时，可以通过一些命令将CPU占用最高的几个线程查看出来

ps -ef | grep java 或者 jps 找到pid
top -Hp pid 找到使用CPU最高的线程
printf '0x%x' tid 线程id转化为16进制
jstack pid |grep tid 找到线程堆栈

除此之外，也可以使用一些外部的检测工具比如arthas

# 3.1.2 Load {#_3-1-2-load}

load指的是一段时间内CPU正在处理及等待的任务数，也是通过top命令：

load average: 0.14，0.21，0.35，分别表示1分钟、5分钟、15分钟内系统的平均负荷。

Load会有两种场景：

CPU高，Load高：先查CPU利用率的问题

CPU不高，Load高：大部分情况都是因为磁盘读写请求过多导致大量IO等待，可通过：

jstack -l pid | grep BLOCKED 查看阻塞态线程堆栈

# 3.1.3 内存 {#_3-1-3-内存}

内存的异常往往可以通过报错得知，常见的异常有如下几种：

OutOfMemoryError：java heap space
OutOfMemoryError: GC overhead limit exceeded  默认情况下, 如果GC花费的时间超过 98%, 并且GC回收的内存少于 2%, JVM就会抛出这个错误
OutOfMemoryError：permgem space 元数据大小超过jvm参数配置
OutOfMemoryError：Metaspace 元数据大小超过jvm参数配置
java.lang.StackOverflowError 一般线程栈溢出是由于递归太深或方法调用层级过多导致的

排查流程如下：

1、查看当前jvm内存的参数配置：jmap -heap pid

2、查看gc情况：jstat -gcutil pid

3、内存dump：jmap -dump:format=b,file=/tmp/dump.dat pid 这个命令在线上慎用，会导致系统变慢

4、内存分析工具分析

# 3.1.4 网络 {#_3-1-4-网络}

出现网络问题的现象主要有两点：

1、http链接无法建立，有大量close_wait的tcp连接

2、tcp重传率高

关于网络问题，我在上家公司刚好遇到过，大量的等待tcp连接导致系统濒临宕机，后来发现是网络带宽500M变成了200M的问题。

# 3.2 数据库层面 {#_3-2-数据库层面}

除了应用之外，第二点可能会出现问题的就是数据库了

# 3.2.1 CPU打满 {#_3-2-1-cpu打满}

数据库服务器的cpu被打满，原因可能是：

1、大数据量查询没有走索引，导致慢sql的出现

2、sql中存在各种导致索引失效的操作

问题解决方式：

通过运维工具（比如rds）找到sql执行时间最长的top10，通过explain查看sql执行是否走了索引，然后加索引优化。

# 3.2.2 网络流量飙升 {#_3-2-2-网络流量飙升}

原因可能是：

1、sql没有设置limit导致全部数据返回

2、sql的请求数量快速增加

解决方式：

1、在搜索代码中务必加上limit

2、运维工具查看异常时间段的sql执行情况

# 3.2.3 系统资源正常，sql一直阻塞 {#_3-2-3-系统资源正常-sql一直阻塞}

原因可能是：

1、一些sql操作导致锁表

解决方式：

1、通过数据库监控工具查找执行时间长的sql

2、将执行时间长的sql直接kill掉

# （四）总体的问题排查流程 {#四-总体的问题排查流程}

第三节主要介绍了详细的问题产生可能原因以及解决办法，这一节主要讲问题的排查流程：

# 4.1 及时收集信息 {#_4-1-及时收集信息}

问题的故障点是很重要的，如果不清楚问题发生的原因，那就说明下次依旧可能发生，因此要将故障信息尽快收集起来，同时做好应用的监控。

# 4.2 定位原因 {#_4-2-定位原因}

问题发生百分之95的原因是近期做了变更，思考近期变更的地方：

1、代码是否有更新

2、数据库是否有变更

3、网络是否做了切换

4、其他应用是否会影响你的应用

5、是否有流量突然变大的情况

同时收集日志、通过工具辅助定位原因，常用的工具有arthas

# 4.3 快速响应 {#_4-3-快速响应}

在尽可能快的时间里将系统还原：

1、如果是代码更新导致，回滚代码

2、如果是数据库变更导致，切换回来

3、如果是网络做了调整，联系网管

4、如果是其他应用的影响，联系其他应用降级

5、如果是流量突然增大，限流

6、实在不知道怎么办，重启

# （五）总结 {#五-总结}

当问题出现时，主要负责人很可能会慌到大脑一片空白，这个时候一定要有人一起解决问题。按照排查的思路，一步步排查。另外很多事故可能是因为一些简单的问题导致，比如网络带宽、索引失效，因此从一些小的问题点出发。