取经阿里十年技术大佬，得到Java线上问题排查攻略！
本文收录于JavaStarter ，里面有我完整的Java系列文章，学习或面试都可以看看
（一）前言
再牛逼的程序员都写不出完美无缺的代码，作为后端开发工程师，一不小心就会遇到线上故障。如果线上故障处理不及时，就可能导致各种严重的后果。恰好最近部门出现了一次挺严重但幸运的是影响面不大的线上故障，最后在阿里工作十年的leader分享了线上问题的排查思路。结合这次分享，写下了这篇Java线上问题排查攻略。
（二）问题发生后的首要工作
一般来说，线上的问题在发生之前会有一系列的预警，比如CPU被打满，网络达到顶峰等等问题。然后就是客户或者用户的反馈，比如某某页面打不开，系统加载很慢，一直提示报错等等。
这个时候的应急操作是首先记录问题发生时的情况：包括服务器的情况，Java虚拟机的一些情况，数据库的连接情况等等，然后尽快让用户能正常使用系统。常用的方法就是系统降级：即让出问题的服务先停掉。或者代码回滚：往往问题都是在代码更新后出现的。或是重启大法，要尽快的保证用户能正常使用。
（三）线上问题异常及可能的原因
出现问题时最先需要记录的是线上的各项异常指标。
3.1 应用层面
应用层面的排查主要是CPU、load、内存以及网络
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
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 内存
内存的异常往往可以通过报错得知，常见的异常有如下几种：
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 网络
出现网络问题的现象主要有两点：
1、http链接无法建立，有大量close_wait的tcp连接
2、tcp重传率高
关于网络问题，我在上家公司刚好遇到过，大量的等待tcp连接导致系统濒临宕机，后来发现是网络带宽500M变成了200M的问题。
3.2 数据库层面
除了应用之外，第二点可能会出现问题的就是数据库了
3.2.1 CPU打满
数据库服务器的cpu被打满，原因可能是：
1、大数据量查询没有走索引，导致慢sql的出现
2、sql中存在各种导致索引失效的操作
问题解决方式：
通过运维工具（比如rds）找到sql执行时间最长的top10，通过explain查看sql执行是否走了索引，然后加索引优化。
3.2.2 网络流量飙升
原因可能是：
1、sql没有设置limit导致全部数据返回
2、sql的请求数量快速增加
解决方式：
1、在搜索代码中务必加上limit
2、运维工具查看异常时间段的sql执行情况
3.2.3 系统资源正常，sql一直阻塞
原因可能是：
1、一些sql操作导致锁表
解决方式：
1、通过数据库监控工具查找执行时间长的sql
2、将执行时间长的sql直接kill掉
（四）总体的问题排查流程
第三节主要介绍了详细的问题产生可能原因以及解决办法，这一节主要讲问题的排查流程：
4.1 及时收集信息
问题的故障点是很重要的，如果不清楚问题发生的原因，那就说明下次依旧可能发生，因此要将故障信息尽快收集起来，同时做好应用的监控。
4.2 定位原因
问题发生百分之95的原因是近期做了变更，思考近期变更的地方：
1、代码是否有更新
2、数据库是否有变更
3、网络是否做了切换
4、其他应用是否会影响你的应用
5、是否有流量突然变大的情况
同时收集日志、通过工具辅助定位原因，常用的工具有arthas
4.3 快速响应
在尽可能快的时间里将系统还原：
1、如果是代码更新导致，回滚代码
2、如果是数据库变更导致，切换回来
3、如果是网络做了调整，联系网管
4、如果是其他应用的影响，联系其他应用降级
5、如果是流量突然增大，限流
6、实在不知道怎么办，重启
（五）总结
当问题出现时，主要负责人很可能会慌到大脑一片空白，这个时候一定要有人一起解决问题。按照排查的思路，一步步排查。另外很多事故可能是因为一些简单的问题导致，比如网络带宽、索引失效，因此从一些小的问题点出发。另外整个流程有一张脑图，如果需要的话可以联系我。我是Java鱼仔，我们下期再见！
