系统运行占用过高

1、CPU过高的问题排查

示例代码：
public class Test {
static class MyThread extends Thread {
public void run() { // 死循环，消耗CPU
int i = 0;
while (true) {
i++;
}
}
}
public static void main(String args[]) throws InterruptedException {
new MyThread().start();
Thread.sleep(10000000);
}
}

(1)使用top命令查看占用CPU过高的进程

(2)top -p进程号 -H。查看进程59648下线程的占用情况，如下图所示

(3)使用如下命令将线程59663转换为16进制表示，如下：

(4)导出CPU占用高进程的线程59663的线程栈。命令如下：

jstack pid >> java.txt

(5)查看线程栈查找原因，打开文件，内容如下：

导出的堆栈信息有线程的状态（一般要找RUNNABLE状态）和调用堆栈结合来查找问题。线程dump分析：线程dump分析主要目的是定位线程长时间停顿的原因
jstack是一个瞬时堆栈只记录瞬时状态，实际排查问题的时候jstack建议打印5次至少3次，根据多次的堆栈内容，再结合相关代码段进行分析，定位高cpu出现的原因，高cpu可能是代码段中某个bug导致的而不是堆栈打印出来的那几行导致的。

(6)cpu高的情况还有一种可能的原因

假如一个4核cpu的服务器我们看到总的cpu达到了100%+，按1之后观察每个cpu的us(用户空间占用cpu的百分比)，只有一个达到了90%+，其他都在1%左右（下图只是演示top按1之后的效果并非真实场景）：

这种情况下可以重点考虑是不是频繁Full GC引起的。因为我们知道Full GC的时候会有Stop The World这个动作，多核cpu的服务器，除了GC线程外，在Stop The World的时候都是会挂起的，直到Stop The World结束。以几种老年代垃圾收集器为例：
Serial Old收集器，全程Stop The World
Parallel Old收集器，全程Stop The World
CMS收集器，它在初始标记与并发标记两个过程中，为了准确标记出需要回收的对象，都会Stop The World，但是相比前两种大大减少了系统停顿时间
无论如何，当真正发生Stop The World的时候，就会出现GC线程在占用cpu工作而其他线程挂起的情况，自然表现也就为某个cpu的us很高而且他cpu的us很低。

2、Java内存过高的问题排查

要详细解释内存分布及回收情况，需要简单重提下Java内存模型。Java内存模型是描述Java程序中各变量（实例域、静态域和数组元素）之间的关系，以及在实际计算机系统中将变量存储到内存和从内存取出变量这样的低层细节。
在Java虚拟机中，内存分为三个代：新生代（New）、老生代（Old）、永久代（Perm）。
（a）新生代New：新建的对象都存放这里
（b）老生代Old：存放从新生代New中迁移过来的生命周期较久的对象。新生代New和老生代Old共同组成了堆内存。
（c）永久代Perm：是非堆内存的组成部分。主要存放加载的Class类级对象如class本身，method，field等等。
如果出现java.lang.OutOfMemoryError: Java heap space异常，说明Java虚拟机的堆内存不够。大概原因：
（a）Java虚拟机的堆内存设置不够，可以通过参数-Xms、-Xmx来调整。
（b）代码中创建了大量大对象，并且长时间不能被垃圾收集器收集（存在被引用）。
如果出现java.lang.OutOfMemoryError: PermGen space，说明是Java虚拟机对永久代Perm内存设置不够。大概原因：
（a）一般出现这种情况，都是程序启动需要加载大量的第三方jar包。例如：在一个Tomcat下部署了太多的应用。
从代码的角度，软件开发人员主要关注java.lang.OutOfMemoryError: Java heap space异常，减少不必要的对象创建，同时避免内存泄漏。

(1)堆dump分析

堆dump分析主要目的是定位OOM异常的原因；解决oom问题四部曲：
A.分析OOM异常的原因，堆溢出？栈溢出？本地内存溢出？
B.如果是堆溢出，导出堆dump，并对堆内存使用有个整体了解；
C.找到最有可能导致内存泄露的元凶，通常也就是消耗内存最多的对象；
D.使用辅助工具对dump文件进行分析；

注意其他几类造成OOM异常的原因

示例代码：
import java.util.ArrayList;
import java.util.List;

public class Test {
private static final int UNIT_MB = 1024 * 1024;

public static void main(String args[]) throws InterruptedException{List<Object> x = new ArrayList<Object>();int i = 0;while(i<1000){x.add(new byte[UNIT_MB]);i++;}Thread.sleep(1000000000);
}

}

(2)jmap dump内存快照

运行示例后，通过top命令查看占用内存高的进程ID，然后通过jmap命令，jmap dump内存快照。
jmap命令有下面几种常用的用法：
•jmap [pid]
•jmap -histo:live [pid] >a.log
•jmap -dump:live,format=b,file=xxx.xxx [pid]
用得最多是后面两个。其中，jmap -histo:live [pid] 可以查看当前Java进程创建的活跃对象数目和占用内存大小。
jmap -dump:live,format=b,file=xxx.xxx [pid] 则可以将当前Java进程的内存占用情况导出来，方便用专门的内存分析工具（例如：MAT）来分析。
命令行输入：
jmap -histo | head -20
就可以查看某个pid的java服务存活的对象占用内存排名前20的类，如下图所示：

可以看到，占用内存最多的是byte字节数组，共有41479个实例。

(3)Jmap内存文件

jmap还有一个指令可以把整个内存情况转成文件形式保存下来，如下：
jmap -dump:format=b,file=filename.hprof
执行命令如下图所示:

可以在JVM启动时设置，如果发生OOM，则dump出文件。命令如下：
-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/tmp/heapdump.hprof

(4)内存文件分析

如果快照文件不大，可以下载到本地，然后通过内存分析工具，如果快照文件很大，可以在服务器上直接分析，使用的命令是：
jhat dump.hprof
jhat也是jdk内置的工具之一。主要是用来分析java堆的命令，可以将堆中的对象以html的形式显示出来，包括对象的数量，大小等等，并支持对象查询语言。命令执行后如下图所示：

访问IP:port，访问如下图所示：

找到下图所示：

其中的Show heap histogram就会显示对象占用内在的大小。如下图所示：

使用内存分析工具时，有时候这个工具还会提示某个对象异常。我们可以在Histogram 页面，可以查看到对象数量排序，我们可以看到 Byte[] 数组排在了第一位，选中对象后右击选择 with incomming reference 功能，可以查看到具体哪个对象引用了这个对象。
可以通过内存分析工具分析dump的文件：
打开工具，file->Open Heap Dump，打开导出的 .hprof 文件

解析完成如下图：

点击上图处，即可查询到占用信息，如下图：

通过上面的步骤后，就能清楚的知道是哪里的代码有问题或者是程序哪里的配置有问题。

3、JVM的Error日志

致命错误日志文件位置可以通过 -XX:ErrorFile进行指定，相关的信息如下：
这个文件主要包含如下内容：
日志头文件
导致 crash 的线程信息
所有线程信息
安全点和锁信息
堆信息
本地代码缓存
编译事件
gc 相关记录
jvm 内存映射
jvm 启动参数
服务器信息
在日志头文件中有常见的描述是“EXCEPTION_STACK_OVERFLOW”，该描述表示这是个栈溢出导致的错误，这往往是应用程序中存在深层递归导致的

4、Full GC的排查

如果FullGC只是发生在老年代区，比较有经验的开发人员还是容易发现问题的，一般都是一些代码bug引起的。MetaSpace发生的FullGC经常会是一些诡异、隐晦的问题，很多和引入的第三方框架使用不当有关或者就是第三方框架有bug导致的，排查起来就很费时间。
YGC如果频繁，会让对象过早进入老年代，如果回收时间过长，会造成系统停顿时间长，造成服务超时等问题。系统中有许多方法可以观察到Full GC，通常有3种方法，如下：

(1)JVM配置参数

在系统中增加参数，记录相关信息，如下：
-XX:+PrintGCDetails -XX:+PrintGCTimeStamps -Xloggc:/home/mazhi/workspace/projectjava/projectjava01/gclog/gc.log
某一次记录的日志信息如下：
Java HotSpot™ 64-Bit Server VM (25.192-b12) for linux-amd64 JRE (1.8.0_192-b12), built on Oct 6 2018 06:46:09 by “java_re” with gcc 7.3.0
Memory: 4k page, physical 8064700k(2091464k free), swap 8276988k(8276988k free)
CommandLine flags: -XX:InitialHeapSize=129035200 -XX:MaxHeapSize=2064563200 -XX:+PrintGC -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:+UseCompressedClassPointers -XX:+UseCompressedOops -XX:+UseParallelGC
0.073: [GC (System.gc()) [PSYoungGen: 634K->320K(36864K)] 634K->320K(121856K), 0.0015284 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]
0.075: [Full GC (System.gc()) [PSYoungGen: 320K->0K(36864K)] [ParOldGen: 0K->258K(84992K)] 320K->258K(121856K), [Metaspace: 2473K->2473K(1056768K)], 0.0035519 secs] [Times: user=0.01 sys=0.00, real=0.00 secs]
Heap
PSYoungGen total 36864K, used 1270K [0x00000000d6f80000, 0x00000000d9880000, 0x0000000100000000)
eden space 31744K, 4% used [0x00000000d6f80000,0x00000000d70bd890,0x00000000d8e80000)
from space 5120K, 0% used [0x00000000d8e80000,0x00000000d8e80000,0x00000000d9380000)
to space 5120K, 0% used [0x00000000d9380000,0x00000000d9380000,0x00000000d9880000)
ParOldGen total 84992K, used 258K [0x0000000084e00000, 0x000000008a100000, 0x00000000d6f80000)
object space 84992K, 0% used [0x0000000084e00000,0x0000000084e40b30,0x000000008a100000)
Metaspace used 2479K, capacity 4486K, committed 4864K, reserved 1056768K
class space used 265K, capacity 386K, committed 512K, reserved 1048576K
给出的信息还是比较全面详细的，包括堆和元空间GC前与GC后的变化，当前虚拟机使用的命令等。

(2)通过监控查看，如Pinpoint APM监控工具等

(3)通过Linux命令查看

通过top命令定位到内存占用过高的进程PID后，排查该进程的GC情况，如：jstat -gc 4383 5000
即会每5秒一次显示进程号为4383的java进程的GC情况。如某次的详细信息如下图所示：

命令：jstat -gccause 41843 2000
即每间隔2s查询进程pid = 41843 的gc情况，gccause表示输出-gcutil提供的信息以及最后一次执行GC的发生原因和当前所执行的GC的发生原因。

当发现是Full GC频繁时，首先要知道，哪些情况下会触发Full GC，原因如下：
程序执行了System.gc();
执行了jmap命令；
大对象直接进入了老年代导致老年代内存不足，达到了GC阈值；
程序中存在内存泄露，导致老年代内存缓慢增长，且无法被回收，达到了GC阈值；
老年代存在内存碎片，导致新晋升的对象空间不足，触发GC。
对于第1个原因，如果老年代还有大量空闲空间时就触发，则有可能是调用了System.gc()。对于后面3个原因，通常需要观察Full GC之前与之后堆的内存变化来确定。可以通过GC日志或jvisualvm等图形化工具来查看，如果Full GC前与后堆回不到原来的大小并且堆大小一直增大，则可能是内存泄露，否则可能就是对象过于频繁进入老年代了，需要找出这些对象。可以通过jmap命令来dump出文件。我们可以在线上开启了 -XX:+HeapDumpBeforeFullGC。使用jvisualvm查看哪些对象占用的比较大的内存（能给出实例占用的大小和占用内存的百分比）

常用到的一些命令及图形化工具如下图所示：

5、其他常用命令如下：

jstat -gc 15712 5000
即会每5秒一次显示进程号为15712的java进成的GC情况。

• S0C: Young Generation第一个survivor space的内存大小 (kB).
• S1C: Young Generation第二个survivor space的内存大小 (kB).
• S0U: Young Generation第一个Survivor space当前已使用的内存大小 (kB).
• S1U: Young Generation第二个Survivor space当前已经使用的内存大小 (kB).
• EC: Young Generation中eden space的内存大小 (kB).
• EU: Young Generation中Eden space当前已使用的内存大小 (kB).
• OC: Old Generation的内存大小 (kB).
• OU: Old Generation当前已使用的内存大小 (kB).
• MC: Permanent Generation的内存大小 (kB)
• MU: Permanent Generation当前已使用的内存大小 (kB).
• YGC: 从启动到采样时Young Generation GC的次数
• YGCT: 从启动到采样时Young Generation GC所用的时间 (s).
• FGC: 从启动到采样时Old Generation GC的次数.
• FGCT: 从启动到采样时Old Generation GC所用的时间 (s).
• GCT: 从启动到采样时GC所用的总时间 (s).

6、常见问题

(1)Java.lang.OutOfMemoryError: PermGen space

PermGen space全称是Permanent Generation space,是指内存的永久保存区域, 这块内存主要是被JVM存放Class和Meta信息的,Class在被Loader时就会被放到PermGen space中, 它和存放类实例(Instance)的Heap区域不同,GC(Garbage Collection)不会在主程序运行期对 PermGen space进行清理，所以如果你的应用中有很多CLASS的话,就很可能出现PermGen space错误。如果你的WEB或者APP用了大量的第三方jar, 其大小超过了jvm默认的大小(4M)那么就会产生此错误信息。
解决方法：
a.调整PermSize、MaxPermSize的大小；
b.减少jar重复使用，重复占用内存。

(2)java.lang.OutOfMemoryError: Java heap space

Heap size 设置 JVM堆的设置是指java程序运行过程中JVM可以调配使用的内存空间的设置.JVM在启动的时候会自动设置Heap size的值，其初始空间(即-Xms)是物理内存的1/64，最大空间(-Xmx)是物理内存的1/4。可以利用JVM提供的-Xmn -Xms -Xmx等选项可进行设置。Heap size 的大小是Young Generation 和Tenured Generaion 之和。
在JVM中，如果98％的时间是用于GC且可用的Heap size 不足2％的时候将抛出此异常信息。提示：Heap Size 最大不要超过可用物理内存的80％，一般的要将-Xms和-Xmx选项设置为相同，而-Xmn为1/4的-Xmx值。
如果发现频繁的gc是因为新生代、老年代、永久代分配的大小有问题，则可以通过修改设置解决。
永久代解决方法（同上）：
a.调整PermSize、MaxPermSize的大小；
b.减少jar重复使用，重复占用内存。
新生代、老年代解决方法：
a.调整Xms -Xmx -Xmn的大小
示例及参数注解：
java -Xmx3550m -Xms3550m -Xmn2g -Xss128k -XX:NewRatio=4 -XX:SurvivorRatio=4 -XX:PermSize=64M -XX:MaxPermSize=128M -XX:MaxTenuringThreshold=0
-Xmx3550m：设置JVM最大可用内存为3550M。
-Xms3550m：设置JVM促使内存为3550m。此值可以设置与-Xmx相同，以避免每次垃圾回收完成后JVM重新分配内存；
-Xmn2g：设置年轻代大小为2G。整个JVM内存大小=年轻代大小 + 年老代大小 + 持久代大小。持久代一般固定大小为64m，所以增大年轻代后，将会减小年老代大小。此值对系统性能影响较大，Sun官方推荐配置为整个堆的3/8；
-Xss128k：设置每个线程的堆栈大小。JDK5.0以后每个线程堆栈大小为1M，以前每个线程堆栈大小为256K。更具应用的线程所需内存大小进行调整。在相同物理内存下，减小这个值能生成更多的线程。但是操作系统对一个进程内的线程数还是有限制的，不能无限生成，经验值在3000~5000左右；
-XX:NewRatio=4:设置年轻代（包括Eden和两个Survivor区）与年老代的比值（除去持久代）。设置为4，则年轻代与年老代所占比值为1：4，年轻代占整个堆栈的1/5；
-XX:SurvivorRatio=4：设置年轻代中Eden区与Survivor区的大小比值。设置为4，则两个Survivor区与一个Eden区的比值为2:4，一个Survivor区占整个年轻代的1/6；
-XX:PermSize=64M JVM初始分配的非堆内存（永久代）；
-XX:MaxPermSize=128M JVM最大允许分配的非堆内存，按需分配；
-XX:MaxTenuringThreshold=0：设置垃圾最大年龄。如果设置为0的话，则年轻代对象不经过Survivor区，直接进入年老代。对于年老代比较多的应用，可以提高效率。如果将此值设置为一个较大值，则年轻代对象会在Survivor区进行多次复制，这样可以增加对象再年轻代的存活时间，增加在年轻代即被回收的概论。