性能优化-内存泄漏、内存溢出、cpu占用高、死锁、栈溢出、FullGC频繁检测手段-总结与分享

介绍

什么是内存泄漏

含义：内层泄露是程序中己动态分配的堆内存由于某种原因程序未释放或无法释放，造成系统内存的浪费。（换言之，GC回收不了这些不再被使用的对象，这些对象的生命周期太长） 危害：当应用程序长时间连续运行时，会导致严重的性能下降；OOM；偶尔会耗尽连接对象；可能导致频繁GC。（大量Full GC发生也可推测系统可能发生内存溢出）

什么是内存溢出

含义：内层溢出通俗理解就是内存不够，程序要求的内存超出了系统所能分配的范围。 危害：内存溢出错误会导致处理数据的任务失败，甚至会引发平台崩溃等严重后果。

什么是CPU飙升

应用程序CPU使用率高，甚至超过100%

什么是死锁

死锁是指两个或两个以上的进程在执行过程中，由于竞争资源或者由于彼此通信而造成的一种阻塞的现象，若无外力作用，它们都将无法推进下去。此时称系统处于死锁状态或系统产生了死锁，这些永远在互相等待的进程称为死锁进程。

什么是栈溢出

Java 里的 StackOverflowError。抛出这个错误表明应用程序因为深递归导致栈被耗尽了。每当java程序启动一个新的线程时，java虚拟机会为他分配一个栈，java栈以帧为单位保持线程运行状态；当线程调用一个方法是，jvm压入一个新的栈帧到这个线程的栈中，只要这个方法还没返回，这个栈帧就存在。 如果方法的嵌套调用层次太多(如递归调用)，随着java栈中的帧的增多，最终导致这个线程的栈中的所有栈帧的大小的总和大于-Xss设置的值，而产生StackOverflowError溢出异常。

内存泄漏、内存溢出、CPU飙升三者之间的关系

内存泄露可能会导致内存溢出。 内存溢出会抛出异常，内存泄露不会抛出异常，大多数时候程序看起来是正常运行的。 内存泄露的程序，JVM频繁进行FullGC尝试释放内存空间，进而会导致CPU飙升 内存泄露过多，造成可回收内存不足，程序申请内存失败，结果就是内存溢出。

基本命令

首先了解各个基本命令、工具的使用，用它们去分析JVM参数，后文案例均是基于以下命令/工具解决。

top free df jps

# 先掌控全局，分别获取执行中的程序进程情况、显示内存的使用情况、查看磁盘剩余空间
top free df 

# 获取java进程的PID
jps 或者ps -ef|grep java

jinfo

可以打印一些当前jvm的各种参数，比如jvm的一些启动参数，jvm中的一些属性k-v等。

jinfo [option] pid

jmap（内存溢出解决方案）

这个命令可以查看JVM内存的一些相关数据

1. 堆历史：可以看到当前JVM中所有已加载内的类创建对象的数量，占用内存等，可以导入文件中查看；

jmap -histo[:live] <pid> [ > ./xx.log]

1. 堆信息：可以查看java程序新生代和老年代的占比即使用情况。

jmap -heap <pid>

1. 堆转储：可以dump堆日志（保存堆现场），再使用visualVM查看jmap生成的堆转储快照。

jmap -dump:live,format=b,file=heap.hprof <pid>

3.1 HeapDump文件 HeapDump 文件是一个二进制文件，它保存了某一时刻JVM堆中对象使用情况（指定时刻Java堆栈的快照），是一种镜像文件。jhat可分析heapdump文件，但是jhat命令在JDK9、JDK10中已经被删除，官方建议用VisualVM代替。 自动导出dump文件：通过JVM参数HeapDumpOnOutOfMemoryError，可以让JVM在出现内存溢出时候Dump出当前的内存转储快照。

# 在IDE中VM option中添加了以下环境变量，程序OOM后生成文件，后缀名为hprof
-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=./

3.2 VisualVM工具

VisualVM 能够监控线程状态、内存使用情况、CPU 使用情况

jstack（cpu占用高解决方案）

这个命令可以查看线程的堆栈信息，定位到简单的死锁，常用的是通过jstack定位CPU高的问题，具体步骤是：

1. 查看当前占用cpu最高的进程pid（COMMAND列）；

top

1. 获取当前进程中所有线程占CPU的情况（也可top -p再按 H）；

top -Hp <pid>

1. 将占用最高的tid转换为16进制

printf "%x\n" <tid>;

1. 查看占用最高的线程的堆栈状态。通过这个流程可以直接定位到哪个线程正在执行占用了大量的cpu。其中A10 就是过滤到关键词之后(A:after)10行信息。

jstack <pid> | grep -A10 <16进制tid>

1. 前面的步骤已经获取了堆栈信息，我们也可以保存线程栈现场到指定文件里分析。

jstack <pid> > jstack.log 

jstat（FullGC频繁解决方案）

这个命令可以查看堆的各个部分的详细的使用情况，可以通过jstat --help查看帮助；

jstat -gc <pid> [1000 10]

查看gc情况，每1秒打印一次总共打印10次(可选)，可以查看各个带的使用总大小和使用大小对于jvm的优化就是要去优化它的FullGC次数，FullGC越少越好，最好控制在FullGC几个小时甚至几天一次，具体看业务的情况。

jstat参数说明：

S0C：第一个幸存区的大小（From Survivor区），以下几个容量的单位都是KB 
S1C：第二个幸存区的大小 （To Survivor区）
S0U：第一个幸存区的使用大小
S1U：第二个幸存区的使用大小 
EC：伊甸园区的大小 （Eden区）