一：堆内存溢出模拟

我们先来做一个堆溢出的测试

1: 改小堆内存的设置

-Xms20m -Xmx20m -XX:-UseGCOverheadLimit 

2：写一段死循环的代码

public class HeapOOMTest {
    public static void main(String[] args) {
        List<OOMObject> userList = new ArrayList<>();

        while (true){
            OOMObject oomObject = new OOMObject();
            oomObject.setBytes(new Byte[1]);
            userList.add(oomObject);
        }
    }

}

@Data
public class OOMObject {
    private Byte bytes[];
}

运行之后，如意得到了异常：java.lang.OutOfMemoryError: Java heap space

Exception in thread "main" java.lang.OutOfMemoryError: Java heap space
	at com.lixiucai.design.oom.HeapOOMTest.main(HeapOOMTest.java:17)

细心的小伙伴可能要问了，上面设置的-XX:-UseGCOverheadLimit 参数是干嘛的？这个是禁用GC overhead limt exceed检查，因为我们堆内存设置的特别小，运行的时候，总是会抛出java.lang.OutOfMemoryError: GC overhead limit exceeded，而不是我们期望的java.lang.OutOfMemoryError: Java heap space，所以我们把它禁用掉。

GC overhead limt exceed检查是Hotspot VM 1.6定义的一个策略，通过统计GC时间来预测是否要OOM了，提前抛出异常，防止OOM发生。Sun 官方对此的定义是：“并行/并发回收器在GC回收时间过长时会抛出OutOfMemroyError。过长的定义是，超过98%的时间用来做GC并且回收了不到2%的堆内存。用来避免内存过小造成应用不能正常工作。“

上面的程序很简单，我们通过代码检查，就会发现是死循环导致的，OOMObject这个对象始终无法被GC释放掉，然后从年轻代的区域，存活到老年代的区域，一直累加，突破了堆内存设定上限，然后OOM。但当代码很多的时候，我们不可能通过这种一行一行检查代码的方式来排查问题，若是有一种工具能还原OOM时，JVM的内存情况就好了，JVN提供了一个参数，使得在OOM的时候可以转储堆内存快照dump文件，然后我们可以使用JDK自带的工具Visual VM来查看分析dump文件。

二：堆内存dump文件生成与分析

1.JVM设置在OOM时生成dump文件

在JVM的参数里设置如下

-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=D:\dump

第一个参数表示在OOM的时候生成dump文件，第二个参数设置生成的dump文件的路径

2.使用Visual VM来分析dump文件

Visual VM，自从 JDK 6 Update 7 以后已经作为 Oracle JDK 的一部分，位于 JDK 根目录的 bin 文件夹下，无需安装，直接运行即可。我们将服务器上生成的dump文件下载到本地，然后使用本地的Visual VM载入它。

点击 文件 --> 装入，然后选择文件类型为 堆Dump,点击打开

 点击堆转储上的线程，可以查看线程日志，然后我们点击 类 页签，显示界面如下

 列表是支 持排序的，我们按实例数或者大小做下倒序，就会发现堆内存里比较大的对象OOMObject排在最前面，然后就是我们要在代码里去找这些大对象出现的地方，排查代码的问题。

三：堆内存溢出的解决方案

1.代码的问题：

排查这些大对象出现的地方，是否有死循环，是否有没有做分页，做全表查询的代码等等。

2.堆内存确实设置的过小，改大它：

-Xms1024m -Xmx1024m

引言

现在做的这个项目后端代码用的是Java语言的，我们用的Tomcat来盛放Java代码。这段时间老是遇到Java堆内存溢出的问题。所以我就查了很多知识，赶紧过来先总结一下，分享交流一下。

堆内存工作原理

Java堆内存管理是影响性性能主要因素之一。堆内存溢出又是Java项目非常常见的故障。在解决问题之前，必须先了解Java堆内存的工作流程。

• JVM内存划分分为堆内存和非堆内存。堆内存分为年轻代、老年代；非堆内存一个永久代。
• 年轻代有分为Eden和Survivor区。Survivor区由FromSpace和ToSpace组成。Eden区占的容量大，Survivor两个区占的容量小。默认比例是8:1:1。
• 堆内存的作用就是用来存放对象。垃圾收集器就是用来收集这些对象，然后根据GC算法回收。
• 非对内存堆放的是永久代，也称为方法区，存储程序运行时长期存活的对象。

在JDK1.8版本废弃了永久代，替代的时元空间(MetaSpace),元空间与永久代类似，都是方法区的实现，他们最大的区别是：元空间并不在JVM中，而是使用本地内存。
元空间由注意有两个参数：

• Metaspacesize：初始化元空间大小，控制发生GC阀值
• MaxMetaspacesize：限制元空间大小上限。防止异常占用过多物理内存。

移除永久代？

移除永久代：
为了融合HotSpot JVM与JRockit VM而做出的改变，因为JRockit没有永久代。有了元空间就可以有效防止出现永久代OOM问题

分代是什么？

新生成的对象首先放到年轻代Eden区，当Eden空间满了，就会触发Minor GC，存活下来的对象移动到Survivor0区，Surviver0满了会再次触发Minor GC，Survivor区存货对象移动到Survivor1区，这样保证了一段时间总有一个Survivor区为空。经过多次Minor GC仍然存活的对象移动到老年代。
老年代存储长期存货的对象，占满时会触发Major GC=Full GC，GC期间会停止所有线程等待GC完成，所以对响应要求高的应用尽量减少发生Major GC，避免响应超时。
Minor GC：清理年轻代
Major GC：清理老年代
Full GC：清理整个堆空间，包括年轻代和永久代
所以GC都会停止应用所有线程

为什么分代？

将对象根据存活概率进行分类，堆存活时间长的对象，放到固定区，从而减少扫描垃圾时间及GC频率。针对分类进行不同的垃圾回收算法，对算法扬长避短。

为什么Survivor分为两块相等大小的幸存空间？

主要为了解决碎片化。如果内存碎片化严重，也就是两个对象占用不连续的内存，已有的连续内存不够新对象存放，就会主动触发GC

JVM堆内存常用参数

垃圾回收算法

• 标记-清除（Mark-Sweep）

GC分为两个阶段，标记和清除。首先标记所有可回收的对象，在标记完成后统一回收所有标记的对象，同时会产生连续的内存碎片化。碎片过多会导致以后程序运行时需要分配较大对象时，无法找到足够的连续内存，而不得再次触发GC

• 复制

将内存按容量划分为两块，每次只使用其中一块。当这块内存用完了，就将存活的对象复制到另一块上，然后再把已使用的内存空间一次清理掉。这样使得每次都是对半个内存区回收，也不用考虑内存碎片化问题，简单高效。缺点需要两倍的内存空间。

• 标记-整理

也分为两个阶段，首先标记可回收的对象，再将存活的对象都向一端移动，然后清理掉边界以外的内存。此方法避免标记-清除算法的碎片化问题，同时也避免了复制算法的空间问题。
一般年轻代中执行GC后，会有少量的对象存活，就会选用复制算法，只要付出少量的存活对象复制成本就可以完成收集、而老年代中因为对象存活率高，没有额外过多的内存空间分配，就需要使用标记-清理活着标记-整理算法来进行回收。

垃圾收集器

串行收集器

比较老的收集器，单线程。收集时，必须暂停应用的工作线程，直到收集结束。

并行收集器

多条垃圾收集线程并行工作，在多核CPU下效率更高，应用线程仍然处于等待状态。

CMS收集器

CMS收集器是缩短暂停应用时间为目标而设计的，是基于标记-清除算法实现，整个过程分为4个步骤，包括：

• 初始化标记
• 并发标记
• 重新标记
• 并发清除

其中，初始标记、重新标记这两个步骤仍然需要暂停应用线程。初始标记只是标记一下GC Roots能直接关联到的对象，速度很快，并发标记阶段是标记可回收对象，而重新标记阶段则是为了修正并发标记期间因用户程序继续运作导致标记产生变动的那一部分对象的标记记录，这个阶段暂停时间比初始标记阶段稍长一点，但远比并发标记时间段。
由于整个过程中消耗最长的并发标记和并发清除过程收集器线程都可以与用户线程一起工作，所以，CMS收集器内存回收与用户一起并发执行的，大大减少了暂停时间。

G1收集器

G1收集器将堆内存划分多个大小相等的独立区域（Region），并且能预测暂停时间，能预测原因它能避免对整个堆进行全区收集。G1跟踪各个Region里的垃圾堆积价值大小（所获得空间大小以及回收所需时间），在后台维护一个优先列表，每次根据允许的收集时间，优先回收价值最大的Region，从而保证了再有限时间内获得更高的收集效率。
G1收集器工作工程分为4个步骤，包括：

• 初始化标记
• 并发标记
• 最终标记
• 筛选回收
  初始标记与CMS一样，标记一下GC Roots能直接关联到的对象。并发标记从GC Root开始标记存活对象，这个阶段耗时比较长，但也可以与应用线程并发执行。而最终标记也是为了修正在并发标记期间因用户程序继续运作而导致标记产生变化的那一部分标记记录。最后在筛选回收阶段对各个Region回收价值和成本进行排序，根据用户所期望的GC暂停时间来执行回收。

垃圾收集器参数

为什么会堆内存溢出

在年轻代中经过GC后还存活的对象会被复制到老年代中。当老年代空间不足，JVM会对老年代进行完全的垃圾回收Full GC。如果Full GC后还是无法存放从Survivor区复制过来的对象，就会出现OOM

OOM常见的几个原因

1）老年代内存不足：java.lang.OutOfMemoryError:Javaheapspace
2）永久代内存不足：java.lang.OutOfMemoryError:PermGenspace
3）代码bug，占用内存无法及时回收。

OOM在这几个内存区都有可能出现，实际遇到OOM时，能根据异常信息定位到哪个区的内存溢出。
可以通过添加个参数-XX:+HeapDumpOnOutMemoryError，让虚拟机在出现内存溢出异常时Dump出当前的内存堆转储快照以便事后分析。

下面是对JAVA应用启动选项调优配置：

JAVA_OPTS="-server -Xms512m -Xmx2g -XX:+UseG1GC -XX:SurvivorRatio=6 -XX:MaxGCPauseMillis=400 -XX:G1ReservePercent=15 -XX:ParallelGCThreads=4 -XX:
ConcGCThreads=1 -XX:InitiatingHeapOccupancyPercent=40 -XX:+PrintGCDetails  -XX:+PrintGCTimeStamps -Xloggc:../logs/gc.log"

• 设置堆内存最小和最大值，最大值参考历史利用率设置
• 设置GC垃圾收集器为G1
• 用GC日志，方便后期分析

总结

• 选择高效的GC算法，可有效减少停止应用线程时间。
• Full GC会增加暂停时间和CPU使用率，可以加大老年代空间大小降低Full GC，但会增加回收时间，根据业务适当取舍。

jVM标准参数

-help
-server -client
-version -showversion
-cp -classpath

X参数

非标准化参数
-Xint：解释执行
-Xcomp：第一次使用就编译成本地代码
-Xmixed：混合模式，JVM自己来决定是否编译成本地代码

XX参数

非标准化参数
相对不稳定
主要用于JVM调优和Debug

Boolean类型

格式：-XX:[±]表示启用或者禁用name属性
比如：-XX:+UserConcMarkSweepGc
-XX:+UseG1GC

非Boolean类型

格式：-XX:= 表示name属性的值是value
比如：-XX:MaxGCPauseMillis=500
-XX:GCTimekRatio=19

-Xms -Xms

不是X参数，而是XX参数
-Xms等价于-XX:InitialHeapSize
-Xms等价于-XX:MaxHeapSize

查看JVM运行时参数

jps专门用来查看java进程的进程ID
-XX:+PrintFlagsInitial
-XX:+PrintFlagsFinal
-XX:+UnlockExperimentalVMOptions解锁实验参数
-XX:+UnlockDiagnosticVMOptions解锁诊断参数
-XX:+PrintCommandLineFlags打印命令行参数

C:\Users\Administrator\Desktop>jps
7352 Jps

C:\Users\Administrator\Desktop>jps -l
4012 sun.tools.jps.Jps

C:\Users\Administrator\Desktop>

jinfo专门针对java进程，通过java进程的进程id，来查看想要查看的信息

jinfo -flag MaxHeapSize javaProcessId

C:\Users\Administrator\Desktop>jinfo -flag MaxHeapSize 4012
4012: no such process

查看最大内存

jinfo -flag MaxHeapSize xx

查看垃圾回收器

jinfo -flag UseConcMarkSweepGc javaProcessId
jinfo -flag UseG1GC javaProcessId
jinfo -flag UseParalelGC javaProcessId

jstat查看JVM统计信息

类装载
垃圾收集
JIT编译

命令格式

options: -class,-compiler,-gc,-printcompilation

-gc 输出结果

SOC, SIC, SOU, S1U : SORS1的总量与使用量
EC, EU : Eden区总量与使用量
OC, OU : Old区总量与使用量
MC, MU : Metaspace区总量与使用量
CCSC, CCSU:压缩类空间总量与使用量
YGC、 YGCT : YoungGC的次数与时间
FGC、 FGCT : FullGC的次数与时间
GCT:总的GC时间

JVM的内存结构

JVM内存结构分为堆区和非堆区。堆区内存是属于JVM内部使用的，而非堆区(在jdk1.8里面叫做Metaspace)是操作系统负责处理的独立于JVM内存之外的。而堆区有分为Young区和Old区。Young区有分为S区和Eden区。
非堆区中的CCS表示压缩类空间，当然非堆区还包含很多块。比如方法：Field，之类的都是在非堆区里面的。

JIT编译

-compiler、-printcompilation
jstat -compiler 3176
jstat -printcompilation 3176

演示内存溢出(jmap + MAT实战内存溢出)

java中所谓的内存溢出和C语言中的内存溢出的概念不是完全相等的。在C语言中，如果一个指针对它所指向的对象失去了引用，那么这就被称为发生了内存泄漏。由于C语言中没有垃圾回收机制，所以失去引用的对象所占用的内存长期得不到释放，所以这个对象所占用的内存也无法分配给别的对象使用，随着事件的堆积，可用的内存就会越来越少，然后就会导致内存溢出。也就是说，内存溢出是由于多次内存泄漏的堆积引起的。在Java中，Java中有垃圾回收机制，所以会把不使用的内存释放出来。但是，如果发生了死循环，就像下面要说的那样，这个对象一直被使用(故无法被垃圾回收机制回收)，当这个对象所占用的内存越来越大时，就会发生内存溢出。在JVM中，可以通过-Xmx和-Xms来分别设置给JVM分配的最大堆内存和最小堆内存。
现在来写代码模拟堆区的内存溢出和非堆区的内存溢出。然后使用MAT来对溢出进行分析内存溢出的原因。

在http://start.spring.io中初始化spring-boot项目

最后点击最下方的即可生成project

演示堆内存溢出

构造User类

package com.imooc.monitor_tuning.chapter2;

public class User {
    private int id;
    private String name;

    public User(int id, String name) {
        this.id = id;
        this.name = name;
    }

    public int getId() {
        return id;
    }

    public void setId(int id) {
        this.id = id;
    }

    public String getName() {
        return name;
    }

    public void setName(String name) {
        this.name = name;
    }
}

定义controller

package com.imooc.monitor_tuning.chapter2;

import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.RestController;

import java.util.ArrayList;
import java.util.List;
import java.util.UUID;

@RestController
public class MemoryController {

    private List<User> userList = new ArrayList<User>();

    /*
    * -Xmx32M -Xms32M      设置最大的堆内存和最小的堆内存
    * */
    @GetMapping("/heap")
    public String heap(){
        int i = 0;
        while(true){
            userList.add(new User(i++, UUID.randomUUID().toString()));
        }
    }
}

在IDEA中设置最大堆内存和最小堆内存的参数

点击Edit Configurations…

设置VM options

启动应用spring boot项目，并在浏览器中访问

在浏览器中输入http://localhost:8080/heap 进行访问

过几秒钟之后就会报OutOfMemory异常：

演示非堆内存溢出

即构造出一个metaspace溢出

添加pom依赖

<dependency>
	<groupId>asm</groupId>
	<artifactId>asm</artifactId>
	<version>3.3.1</version>
</dependency>

编写Metaspace类

可以参考：https://blog.csdn.net/bolg_hero/article/details/78189621

package com.imooc.monitor_tuning.chapter2;

import java.util.ArrayList;
import java.util.List;

import org.objectweb.asm.ClassWriter;
import org.objectweb.asm.MethodVisitor;
import org.objectweb.asm.Opcodes;

/*
 * 继承ClassLoader是为了方便调用defineClass方法，因为该方法的定义为protected
 * */
public class Metaspace extends ClassLoader {
    public List<Class<?>> createAllCla() {
        // 类持有
        List<Class<?>> classes = new ArrayList<Class<?>>();
        // 循环1000w次生成1000w个不同的类。
        for (int i = 0; i < 1000; ++i) {
            ClassWriter cw = new ClassWriter(0);
            // 定义一个类名称为Class{i}，它的访问域为public，父类为java.lang.Object，不实现任何接口
            cw.visit(Opcodes.V1_1, Opcodes.ACC_PUBLIC, "Class" + i, null,
                    "java/lang/Object", null);
            // 定义构造函数<init>方法
            MethodVisitor mw = cw.visitMethod(Opcodes.ACC_PUBLIC, "<init>",
                    "()V", null, null);
            // 第一个指令为加载this
            mw.visitVarInsn(Opcodes.ALOAD, 0);
            // 第二个指令为调用父类Object的构造函数
            mw.visitMethodInsn(Opcodes.INVOKESPECIAL, "java/lang/Object", "<init>",
                    "()V");
            // 第三条指令为return
            mw.visitInsn(Opcodes.RETURN);
            mw.visitMaxs(1, 1);
            mw.visitEnd();

            Metaspace test = new Metaspace();
            byte[] code = cw.toByteArray();
            // 定义类
            Class<?> exampleClass = test.defineClass("Class" + i, code, 0, code.length);
            classes.add(exampleClass);
        }
        return classes;
    }
}

对应的处理请求的controller

private List<Class<?>> classList = new ArrayList<Class<?>>();
/*
* 设置最小的metaspace size为32M，设置最大的metaspace size也为32M
* -XX:MetaspaceSize=32M -XX:MaxMetaspaceSize=32M
* */
@GetMapping("/nonheap")
public String nonheap(){
    Metaspace ms = new Metaspace();
    while(true){//这是就需要动态地生成class，可以使用asm，因此需要在pom以来中引入依赖
        classList.addAll(ms.createAllCla());
    }
}

在浏览器中进行访问

非堆内存溢出异常

java.lang.OutOfMemoryError: Metaspace
	at java.lang.ClassLoader.defineClass1(Native Method) ~[na:1.8.0_181]
	at java.lang.ClassLoader.defineClass(ClassLoader.java:763) ~[na:1.8.0_181]
	at java.lang.ClassLoader.defineClass(ClassLoader.java:642) ~[na:1.8.0_181]
	at com.imooc.monitor_tuning.chapter2.Metaspace.createAllCla(Metaspace.java:39) ~[classes/:na]
	at com.imooc.monitor_tuning.chapter2.MemoryController.nonheap(MemoryController.java:36) ~[classes/:na]
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[na:1.8.0_181]
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) ~[na:1.8.0_181]
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[na:1.8.0_181]
	at java.lang.reflect.Method.invoke(Method.java:498) ~[na:1.8.0_181]
	at org.springframework.web.method.support.InvocableHandlerMethod.doInvoke(InvocableHandlerMethod.java:190) ~[spring-web-5.1.9.RELEASE.jar:5.1.9.RELEASE]
	at org.springframework.web.method.support.InvocableHandlerMethod.invokeForRequest(InvocableHandlerMethod.java:138) ~[spring-web-5.1.9.RELEASE.jar:5.1.9.RELEASE]
	at org.springframework.web.servlet.mvc.method.annotation.ServletInvocableHandlerMethod.invokeAndHandle(ServletInvocableHandlerMethod.java:104) ~[spring-webmvc-5.1.9.RELEASE.jar:5.1.9.RELEASE]
	at org.springframework.web.servlet.mvc.method.annotation.RequestMappingHandlerAdapter.invokeHandlerMethod(RequestMappingHandlerAdapter.java:892) ~[spring-webmvc-5.1.9.RELEASE.jar:5.1.9.RELEASE]
	at org.springframework.web.servlet.mvc.method.annotation.RequestMappingHandlerAdapter.handleInternal(RequestMappingHandlerAdapter.java:797) ~[spring-webmvc-5.1.9.RELEASE.jar:5.1.9.RELEASE]
	at org.springframework.web.servlet.mvc.method.AbstractHandlerMethodAdapter.handle(AbstractHandlerMethodAdapter.java:87) ~[spring-webmvc-5.1.9.RELEASE.jar:5.1.9.RELEASE]
	at org.springframework.web.servlet.DispatcherServlet.doDispatch(DispatcherServlet.java:1039) ~[spring-webmvc-5.1.9.RELEASE.jar:5.1.9.RELEASE]
	at org.springframework.web.servlet.DispatcherServlet.doService(DispatcherServlet.java:942) ~[spring-webmvc-5.1.9.RELEASE.jar:5.1.9.RELEASE]
	at org.springframework.web.servlet.FrameworkServlet.processRequest(FrameworkServlet.java:1005) ~[spring-webmvc-5.1.9.RELEASE.jar:5.1.9.RELEASE]
	at org.springframework.web.servlet.FrameworkServlet.doGet(FrameworkServlet.java:897) ~[spring-webmvc-5.1.9.RELEASE.jar:5.1.9.RELEASE]
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:634) ~[tomcat-embed-core-9.0.22.jar:9.0.22]
	at org.springframework.web.servlet.FrameworkServlet.service(FrameworkServlet.java:882) ~[spring-webmvc-5.1.9.RELEASE.jar:5.1.9.RELEASE]
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:741) ~[tomcat-embed-core-9.0.22.jar:9.0.22]
	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:231) ~[tomcat-embed-core-9.0.22.jar:9.0.22]
	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166) ~[tomcat-embed-core-9.0.22.jar:9.0.22]
	at org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:53) ~[tomcat-embed-websocket-9.0.22.jar:9.0.22]
	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193) ~[tomcat-embed-core-9.0.22.jar:9.0.22]
	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166) ~[tomcat-embed-core-9.0.22.jar:9.0.22]
	at org.springframework.web.filter.RequestContextFilter.doFilterInternal(RequestContextFilter.java:99) ~[spring-web-5.1.9.RELEASE.jar:5.1.9.RELEASE]
	at org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:118) ~[spring-web-5.1.9.RELEASE.jar:5.1.9.RELEASE]
	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193) ~[tomcat-embed-core-9.0.22.jar:9.0.22]
	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166) ~[tomcat-embed-core-9.0.22.jar:9.0.22]
	at org.springframework.web.filter.FormContentFilter.doFilterInternal(FormContentFilter.java:92) ~[spring-web-5.1.9.RELEASE.jar:5.1.9.RELEASE]