故障分析
# 导致系统不可用情况（频率较大）：
1）代码中某个位置读取数据量较大，导致系统内存耗尽，进而出现Full GC次数过多，系统缓慢；
2）代码中有比较消耗CPU的操作，导致CPU过高，系统运行缓慢；
# 导致某功能运行缓慢（不至于导致系统不可用）：
3）代码某个位置有阻塞性的操作，导致调用整体比较耗时，但出现比较随机；
4）某线程由于某种原因进入WAITTING状态，此时该功能整体不可用，但无法复现；
5）由于锁使用不当，导致多个线程进入死锁状态，导致系统整体比较缓慢。
# 说明
对于后三种情况而言，是具有一定阻塞性操作，CPU和系统内存使用情况都不高，但功能却很慢，所以通过查看资源使用情况是无法查看出具体问题的！
应急处理
### 对于线上系统突然产生的运行缓慢问题，如果导致线上系统不可用。首先要做的是导出jstack和内存信息，重启服务器，尽快保证系统的高可用。
### 导出jstack信息
为避免重复赘述，此操作将在后面的"排查步骤"章节中体现！
### 导出内存堆栈信息
# 查看要导出的Java项目的pid
# jps -l
or
# ps -ef |grep java
# 导出内存堆栈信息
jmap -dump:live,format=b,file=heap8
# 运行导出的堆栈文件
# ls
heap8
# hostname -I
10.2.2.162
# jhat -port 9998 heap8
# 浏览器访问http://10.2.2.162:9998/
排查步骤
# 环境说明
因平台做了线上推广，导致管理平台门户网页进统计页面请求超时，随进服务器操作系统查看负载信息，load average超过了4，负载较大，PID为7163的进程cpu资源占用较高。
# 定位故障
# 处理思路：
找出CPU占用率高的线程，再通过线程栈信息找出该线程当时正在运行的问题代码段。
# 操作如下：
# 查看高占用的"进程"中占用高的"线程"
# top -Hbp 7163 | awk '/java/ && $9>50'
# 将16298的线程ID转换为16进制的线程ID
# printf "%x\n" 16298
3faa
# 通过jvm的jstack查看进程信息并保存以供研发后续分析
# jstack 7163 | grep "3faa" -C 20 > 7163.log
# 重点说明
通过排查步骤，可得排查问题需要掌握的信息如下：
1）资源占用高对应的进程a的PID;
2）进程a对应的资源占用高且最频繁的线程b的ID；
3）将线程b的ID转换为16进制的ID。
数据库问题引发的资源占用过高
## 通过"排查步骤"章节可基本定位问题，后续请见下文！
确认问题及处理
# jstack $pid | grep "3faa" -C 20 # 3faa指的是高占用进程中的高占用的线程对应的16进制id；
# 查看到是数据库的问题，排查思路：先打印所有在跑的数据库线程，检查后发现并跟进情况找到问题表；
# 打印MySQL现有进程信息文件
# mysql -uroot -p -e "show full processlist" > mysql_full_process.log
# 过滤出查询最多的表
grep Query mysql_full_process.log
# 统计查询最多的表的数据量
> use databases_name；
> select count(1) from table_name；
# 结合MySQL日志信息，可判断问题是查询时间过长导致，排查后发现表未创建索引；
> show create table table_name\G
# 询问研发，确认数据不重要，检查字段由时间字段，根据时间确认只保留一个月的数据；
> delete from table_name where xxxx_time < '2019-07-01 00:00:00' or xxxx_time is null;
# 创建索引
> alter table table_name add index (device_uuid);
# 确认索引是否创建
> show create table table_name;
总结
处理后进程的CPU占用降至正常水平，本次排查主要用到了jvm进程查看及dump进程详细信息的操作，确认是由数据库问题导致的原因，并对数据库进行了清理并创建了索引。
在处理问题后，又查询了一下数据库相关问题的优化，通常的优化方法还是添加索引。该方法添加参数具体如下：
innodb_buffer_pool_size=4G
Full GC次数过多
## 通过"排查步骤"章节可基本定位问题，后续请见下文！
确认问题及处理
# 特征说明
对于Full GC较多的情况，有以下特征：
1）进程的多个线程的CPU使用率都超过100%，通过jstack命令可看到大部分是垃圾回收线程；
2）通过jstat查看GC情况，可看到Full GC次数非常多，并数值在不断增加。
# 3faa指的是高占用进程中的高占用的线程对应的16进制id；
# jstack $pid | grep "3faa" -C 20
说明：VM Thread指垃圾回收的线程。故基本可确定，当前系统缓慢的原因主要是垃圾回收过于频繁，导致GC停顿时间较长。
# 查看GC情况（1000指间隔1000ms，4指查询次数）
# jstat -gcutil $pid 1000 4
说明：FGC指Full GC数量，其值一直在增加，图中显现高达6783，进一步证实是由于内存溢出导致的系统缓慢。
# 因笔者是运维，故确认了问题后，Dump内存日志后交由研发解决代码层面问题！
总结
# 对于Full GC次数过大，主要有以下两种原因：
1）代码中一次性获取大量对象，导致内存溢出（可用Eclipse的Mat工具排查）；
2）内存占用不高，但Full GC数值较大，可能是显示的System.gc()调用GC次数过多，可通过添加 -XX:+DisableExplicitGC 来禁用JVM 对显示 GC 的响应。
服务不定期出现接口响应缓慢
情况说明
某个接口访问经常需要3~4s甚至更长时间才能返回。一般而言，其消耗的CPU和内存资源不多，通过上述方式排查问题无法行通。
由于接口耗时较长问题不定时出现，导致通过jstack命令得到线程访问的堆栈信息，根据其信息也不一定能定位到导致耗时操作的线程（概率事件）。
定位思路
在排除网络因素后，通过压测工具对问题接口不断加大访问力度。当该接口中有某个位置是比较耗时的，由于访问的频率高，将导致大多数的线程都阻塞于该阻塞点。
通过分析多个线程日志，能得到相同的TIMED_WAITING堆栈日志，基本上就可定位到该接口中较耗时的代码的位置。
# 示例
# 代码中有比较耗时的阻塞操作，通过压测工具得到的线程堆栈日志，如下：
说明：由图可得，多个线程都阻塞在了UserController的第18行，说明此时一个阻塞点，也是导致该接口较缓慢的原因。
大总结
# 总体性的分析思路
当Java应用出现问题时，处理步骤如下：
通过 top 命令定位异常进程pid，再 top -Hp
# 此处根据日志信息分析，可分为两种情况，如下：
# A情况
A.a）若用户线程正常，则通过该线程的堆栈信息查看比较消耗CPU的具体代码区域；
A.b）若是VM Thread，则通过 jstat -gcutil
# B情况
若通过top命令查看到CPU和内存使用率不高，则可考虑以下三种情况。
B.a）若是不定时出现接口耗时过长，则可通过压测方式增大阻塞点出现的概率，从而通过jstack命令查看堆栈信息，找到阻塞点；
B.b）若是某功能访问时突然出现停滞（异常）状况，重启后又正常了，同时也无法复现。此时可通过多次导出jstack日志的方式，对比并定位出较长时间处于等待状态的用户线程，再从中筛选出问题线程；
B.c）若通过jstack命令查看到死锁状态，则可检查产生死锁的线程的具体阻塞点，进而相应处理。