CPU飙高，OOM排查？
对于线上系统突然产生的运行缓慢问题，如果该问题导致线上系统不可用，那么首先需要做的就是，导出jstack和内存信息，然后重启系统，尽快保证系统的可用性。这种情况可能的原因主要有两种：
-
代码中某个位置读取数据量较大，导致系统内存耗尽，从而导致Full GC次数过多，系统缓慢；
-
代码中有比较耗CPU的操作，导致CPU过高，系统运行缓慢；
相对来说，这是出现频率最高的两种线上问题
CPU高很多
查看
主要原因
https://blog.csdn.net/weiwosuoai/article/details/100038857
-
代码中某个位置读取数据量较大，导致系统内存耗尽，从而导致Full GC次数过多，系统缓慢；
- top top -HP jstack查看是否有频繁垃圾回收
- jstat -gcutil 9(进程) 1000 10查看GC情况 可以看到，这里FGC指的是Full GC数量，这里高达6793，而且还在不断增长。从而进一步证实了是由于内存溢出导致的系统缓慢。那么这里确认了内存溢出，但是如何查看你是哪些对象导致的内存溢出呢，这个可以dump出内存日志，然后通过eclipse的mat工具进行查看，如下是其展示的一个对象树结构：
-
代码中有比较耗CPU的操作，导致CPU过高，系统运行缓慢；在这里我们就可以区分导致CPU过高的原因具体是Full GC次数过多还是代码中有比较耗时的计算了。如果是Full GC次数过多，那么通过jstack得到的线程信息会是类似于VM Thread之类的线程，而如果是代码中有比较耗时的计算，那么我们得到的就是一个线程的具体堆栈信息。如下是一个代码中有比较耗时的计算，导致CPU过高的线程信息：
-
不定期出现的接口耗时现象
OOM故障 分析
内存不够 先查看下内存 可以先把jvm内存调大恢复java , 重新设置合适的JVM 初始堆与最大堆内存 ,重新设置 swap交换空间大小
top查看应用的占用信息
查看堆栈
引用自https://blog.csdn.net/xiehd313/article/details/90231768
cpu飙高处理步骤
1. top查找出哪个进程消耗的CPU高(top -c)
2. top -h -p查找出哪个线程消耗的cpu高（top -h -p pid）
这个命令就能显示刚刚找到的进程的所有线程的资源消耗情况。
3. printf％x进行pid的进制转换
找到CPU负载高的线程pid 8627, 把这个数字转换成16进制，21B3（10进制转16进制，用linux命令: printf %x 8627）
4. jstack记录进程的堆栈信息
执行jstack -l pid，拿到进程的线程dump文件。这个命令会打出这个进程的所有线程的运行堆栈。
5. 找出消耗CPU最高的线程信息
搜索“21B3”，就是搜一下16进制显示的线程id。搜到后，下面的堆栈就是这个线程打出来的。
内存飙高处理步骤
1. jstat命令查看FGC发生的次数和消耗的时间，次数越多，耗时越长说明存在问题;
Jstat命令可以观察到classloader，compiler，gc相关信息。可以时时监控资源和性能
2. 连续查看jmap -heap查看老生代的占用情况，变化越大说明程序存在问题;
Jmap命令（jmap [ option ] pid）得到运行java程序的内存分配的详细情况。例如实例个数，大小等
3. 使用连续的jmap -histo：live命令导出文件，比对加载对象的差异，差异部分一般是发生问题的地方。
GC引起的单核飙高
1. 单个CPU占用率高，首先从GC查起。
常见SY飙高
1.线程上下文切换频繁
2. 线程太多
3. 锁竞争激烈
IO飙高
1. 如果IO的CPU占用很高，排查涉及到IO的程序，比如把OIO改造成NIO。
抖动问题
原因：字节码转为机器码需要占用CPU时间片，大量的CPU在执行字节码时，导致CPU长期处于高位;
现象：“C2 CompilerThread1”守护进程，“C2 CompilerThread0”守护进程CPU占用率最高;
解决办法：保证编译线程的CPU占比
