java进程等待时间_Java进程故障排查（CPU资源占用高，接口响应超时

# 创建索引
> alter tableadd index ();
# 确认索引是否创建
> showtable ;
总结
处理后进程的CPU占用降至正常水平，本次排查主要用到了jvm进程查看及dump进程详细信息的操作，确认是由数据库问题导致的原因，并对数据库进行了清理并创建了索引。
在处理问题后，又查询了一下数据库相关问题的优化，通常的优化方法还是添加索引。该方法添加参数具体如下：
ize=4G
Full GC次数过多
## 通过"排查步骤"章节可基本定位问题，后续请见下文！
确认问题及处理
# 特征说明
对于Full GC较多的情况，有以下特征：
1)进程的多个线程的CPU使用率都超过100%，通过命令可看到大部分是垃圾回收线程；
【java进程等待时间_Java进程故障排查（CPU资源占用高，接口响应超时】2)通过jstat查看GC情况，可看到Full GC次数非常多，并数值在不断增加。
# 3faa指的是高占用进程中的高占用的线程对应的16进制id；
#$pid | grep "3faa" -C 20
说明：VM 指垃圾回收的线程。故基本可确定，当前系统缓慢的原因主要是垃圾回收过于频繁，导致GC停顿时间较长。
# 查看GC情况(1000指间隔，4指查询次数)
# jstat - $pid 1000 4
说明：FGC指Full GC数量，其值一直在增加，图中显现高达6783，进一步证实是由于内存溢出导致的系统缓慢。
# 因笔者是运维，故确认了问题后，Dump内存日志后交由研发解决代码层面问题！
总结
# 对于Full GC次数过大，主要有以下两种原因：
1)代码中一次性获取大量对象，导致内存溢出(可用的Mat工具排查)；
2)内存占用不高，但Full GC数值较大，可能是显示的.gc()调用GC次数过多，可通过添加 -XX:+ 来禁用JVM 对显示 GC 的响应。
服务不定期出现接口响应缓慢
情况说明
某个接口访问经常需要3~4s甚至更长时间才能返回。一般而言，其消耗的CPU和内存资源不多，通过上述方式排查问题无法行通。
由于接口耗时较长问题不定时出现，导致通过命令得到线程访问的堆栈信息，根据其信息也不一定能定位到导致耗时操作的线程(概率事件) 。
定位思路
在排除网络因素后，通过压测工具对问题接口不断加大访问力度。当该接口中有某个位置是比较耗时的，由于访问的频率高，将导致大多数的线程都阻塞于该阻塞点。

文章插图
通过分析多个线程日志，能得到相同的堆栈日志，基本上就可定位到该接口中较耗时的代码的位置。
# 示例
# 代码中有比较耗时的阻塞操作，通过压测工具得到的线程堆栈日志，如下：
说明：由图可得，多个线程都阻塞在了的第18行，说明此时一个阻塞点，也是导致该接口较缓慢的原因。
大总结
# 总体性的分析思路
当Java应用出现问题时，处理步骤如下：
通过 top 命令定位异常进程pid，再 top -Hp 命令定位出CPU资源占用较高的线程的id，并将其线程id转换为十六进制的表现形式，再通过| grep 命令查看日志信息，定位具体问题。
# 此处根据日志信息分析，可分为两种情况，如下：
# A情况
A.a)若用户线程正常，则通过该线程的堆栈信息查看比较消耗CPU的具体代码区域；
A.b)若是VM ，则通过 jstat - 命令查看当前GC状态，然后通过 jmap -dump:live,=b,file= 导出当前系统内存数据，用的Mat工具进行分析，进而针对比较消耗内存的代码区进行相关优化。
# B情况
若通过top命令查看到CPU和内存使用率不高，则可考虑以下三种情况。