1）什么是OOM？
OOM，全称“Out Of Memory”，翻译成中文就是“内存用完了”，来源于java.lang.OutOfMemoryError。看下关于的官方说明： Thrown when the Java Virtual Machine cannot allocate an object because it is out of memory, and no more memory could be made available by the garbage collector. 意思就是说，当JVM因为没有足够的内存来为对象分配空间并且垃圾回收器也已经没有空间可回收时，就会抛出这个error（注：非exception，因为这个问题已经严重到不足以被应用处理）。
2）为什么会OOM？
1）分配的少了：比如虚拟机本身可使用的内存（一般通过启动时的VM参数指定）太少。或者不同 JVM 区域分配内存不合理；
2）应用用的太多，并且用完没释放，浪费了。此时就会造成内存泄露或者内存溢出。某一个对象被频繁申请，不用了之后却没有被释放，发生内存泄漏，导致内存耗尽（比如ThreadLocal泄露）
内存泄露：申请使用完的内存没有释放，导致虚拟机不能再次使用该内存，此时这段内存就泄露了，因为申请者不用了，而又不能被虚拟机分配给别人用。
内存溢出：申请的内存超出了JVM能提供的内存大小，此时称之为溢出。
在之前没有垃圾自动回收的日子里，比如C语言和C++语言，我们必须亲自负责内存的申请与释放操作，如果申请了内存，用完后又忘记了释放，比如C++中的new了但是没有delete，那么就可能造成内存泄露。偶尔的内存泄露可能不会造成问题，而大量的内存泄露可能会导致内存溢出。
而在Java语言中，由于存在了垃圾自动回收机制，所以，我们一般不用去主动释放不用的对象所占的内存，也就是理论上来说，是不会存在“内存泄露”的。但是，如果编码不当，比如，将某个对象的引用放到了全局的Map中，虽然方法结束了，但是由于垃圾回收器会根据对象的引用情况来回收内存，导致该对象不能被及时的回收。如果该种情况出现次数多了，就会导致内存溢出，比如系统中经常使用的缓存机制。Java中的内存泄露，不同于C++中的忘了delete，往往是逻辑上的原因泄露。
场景一：堆内存OOM（也叫堆内存溢出）
这是最常见的OOM场景了，发生在JVM试图分配对象空间时，却发现剩余的堆内存不足以存储新对象。
例如我们执行下面的代码，就可以模拟出堆内存OOM的场景：
// 创建大量对象导致堆内存溢出
public class HeapOOM {
static class OOMObject {
// 假设这里有一些属性
}
public static void main(String[] args) {
List<OOMObject> list = new ArrayList<>();
while (true) {
list.add(new OOMObject()); // 不断创建对象并添加到list中
}
}
}那么当出现线上应用OOM场景时，该如何解决呢？
分析方法通常有两种：
- 类型一：在线分析，属于轻量级的分析：
- 类型二：离线分析，属于重量级的分析：
类型一：在线OOM分析：
在线分析Java OOM（内存溢出）问题，通常涉及到监控运行中的Java应用，捕获内存溢出时的信息，分析堆转储（Heap Dump）文件，以及利用一些工具和命令来辅助定位问题。下面是一套详细的分析流程和命令，帮助你在线分析和解决Java OOM问题：
1、启用JVM参数以捕获Heap Dump
在Java应用启动命令中加入以下JVM参数，以确保在发生OOM时能自动生成堆转储文件：
-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/path/to/heapdump.hprof这些参数的作用是：
-XX:+HeapDumpOnOutOfMemoryError：指示JVM在遇到OOM错误时生成堆转储文件。-XX:HeapDumpPath：指定堆转储文件的存储路径，可以自定义路径和文件名。
2、实时监控内存使用情况
使用jvisualvm或jconsole等工具可以实时监控Java应用的内存使用情况。这些工具可以帮助你了解内存消耗的趋势，从而预测和避免OOM的发生。
- JVisualVM：集成了多个JDK命令行工具，提供了可视化界面，可以监控内存使用、查看线程、分析堆等。
- JConsole：Java监控和管理控制台，用于对JVM中的内存、线程和类等进行监控。
3、分析Heap Dump文件
当应用抛出OOM并且根据上述设置生成了堆转储文件后，使用Heap Dump分析工具来分析这个文件。常用的工具有：
- Eclipse Memory Analyzer (MAT)：一个强大的Java堆分析工具，可以帮助识别内存泄露和查看内存消耗情况。
- VisualVM：除了监控功能外，也支持加载和分析Heap Dump文件。
在MAT中打开Heap Dump文件，主要关注以下几点：
- 查找内存中对象的分布，特别是占用内存最多的对象。
- 分析这些对象的引用链，确定是哪部分代码引起的内存泄漏或过度消耗。
- 检查ClassLoader，以确认是否有过多的类被加载导致的元空间（Metaspace）OOM。
4、使用命令行工具
JDK提供了一些命令行工具，如jmap，可以用来生成Heap Dump文件：
jmap -dump:live,format=b,file=heapdump.hprof <pid>其中<pid>是Java进程的ID。-dump:live选项表示只转储活动对象，可以减小Heap Dump文件的大小。
5、分析日志和异常信息
最后，不要忽视应用的日志和抛出的异常信息。OOM之前的日志可能会提供一些导致内存溢出的操作或业务逻辑的线索。
类型二：离线OOM分析，这个属于重量级分析
离线分析Java OOM（OutOfMemoryError）通常是在问题发生后，通过分析JVM生成的堆转储（Heap Dump）文件来进行。这个过程涉及到获取堆转储文件、使用分析工具进行深入分析和解读分析结果
1、获取Heap Dump文件
首先，确保你已经有了一个Heap Dump文件。这个文件可能是在JVM遇到OOM时自动生成的（如果启用了-XX:+HeapDumpOnOutOfMemoryError JVM参数），或者你可以在应用运行期间手动生成：
-
使用
jmap命令生成Heap Dump文件：jmap -dump:live,format=b,file=/path/to/heapdump.hprof <pid>其中
<pid>是Java进程的ID，/path/to/heapdump.hprof是你希望保存Heap Dump文件的位置。
2、使用Heap Dump分析工具
有了Heap Dump文件后，你需要使用专门的工具来进行分析。以下是一些常用的分析工具：
- Eclipse Memory Analyzer (MAT)：非常强大的内存分析工具，能帮助识别内存泄漏和查看内存消耗情况。
- VisualVM：提供了一个可视化界面，可以用来分析Heap Dump文件。
- JVisualVM：随JDK一起提供的工具，也支持加载Heap Dump文件进行分析。
3、分析Heap Dump文件
使用MAT（Eclipse Memory Analyzer）作为示例，分析流程如下：
- 打开Heap Dump文件：启动MAT并打开Heap Dump文件（.hprof）。
- 运行Leak Suspects Report：MAT可以自动生成一个内存泄漏报告（Leak Suspects Report），这个报告会指出可能的内存泄漏路径。
- 分析Dominators Tree：这个视图显示了占用最多内存的对象及其引用。通过它，你可以找到最大的内存消耗者。
- 查看Histogram：对象Histogram列出了所有对象的实例数和总大小，帮助你识别哪种类型的对象占用了最多的内存。
- 检查GC Roots：为了确定对象为什么没有被垃圾回收，可以查看对象到GC Roots的引用链。
- 分析引用链：通过分析对象的引用链，你可以确定是什么持有了这些对象的引用，导致它们无法被回收。
下面给大家提供一份Java应用上线前参考的的JVM配置（内存8G）,以后系统上线前可以先配置下JVM，不要啥都不配置就上线了
-Xms6g -Xmx6g （按不同容器，4G及以下建议为50%，6G以上，建议设置为70%）
-Xmn2g (以8G内存，年轻代可以设置为2G)
-XX:MetaspaceSize=256m
-XX:MaxMetaspaceSize=512m
-Xss256k
-XX:+UseG1GC
-XX:MaxGCPauseMillis=200
-XX:AutoBoxCacheMax=20000
-XX:+HeapDumpOnOutOfMemoryError （当JVM发生OOM时，自动生成DUMP文件）
-XX:HeapDumpPath=/usr/local/logs/gc/
-XX:ErrorFile=/usr/local/logs/gc/hs_err_%p.log （当JVM发生崩溃时，自动生成错误日志）
-XX:+PrintGCApplicationStoppedTime
-XX:+PrintGCDetails
-XX:+PrintGCDateStamps
-Xloggc:/usr/local/heap-dump/场景二：元空间（MetaSpace）OOM
什么是元空间？
Java元空间（Metaspace）是Java虚拟机（JVM）中用于存放类的元数据的区域，从Java 8开始引入，替代了之前的永久代（PermGen）
图中红色箭头所指就是元空间
元空间是方法区在HotSpot JVM 中的实现，方法区主要用于存储类的信息、常量池、方法数据、方法代码等。方法区逻辑上属于堆的一部分，但是为了与堆进行区分，通常又叫“非堆”。
元空间的本质和永久代类似，都是对JVM规范中方法区的实现。
不过元空间与永久代之间最大的区别在于：元空间并不在虚拟机中，而是使用本地内存。理论上取决于32位/64位系统可虚拟的内存大小，可见也不是无限制的，需要配置参数。
元空间(Metaspace) 垃圾回收，会对僵死的类及类加载器的垃圾回收会进行回收，元空间(Metaspace) 垃圾回收的时机是，在元数据使用达到“MaxMetaspaceSize”参数的设定值时进行。
元空间OOM的现象
JVM 在启动后或者某个时间点开始，MetaSpace 的已使用大小在持续增长，同时每次 GC 也无法释放，调大 MetaSpace 空间也无法彻底解决。
元空间OOM的核心原因：生成了大量动态类
比如：
- 使用大量动态生成类的框架（如某些ORM框架、动态代理技术、热部署工具等）
- 程序代码中大量使用反射，反射在大量使用时，因为使用缓存的原因，会导致ClassLoader和它引用的Class等对象不能被回收
例如下面的生成大量动态代理类的代码示例，则会导致元空间的OOM
// 使用CGLIB动态生成大量类导致元空间溢出
public class MetaspaceOOM {
public static void main(String[] args) {
while (true) {
Enhancer enhancer = new Enhancer();
enhancer.setSuperclass(OOMObject.class);
enhancer.setUseCache(false);
enhancer.setCallback(new MethodInterceptor() {
public Object intercept(Object obj, Method method, Object[] args, MethodProxy proxy) throws Throwable {
return proxy.invokeSuper(obj, args);
}
});
enhancer.create(); // 动态生成类并加载
}
}
static class OOMObject {
// 这里可以是一些业务方法
}
}
元空间(Metaspace) OOM 解决办法：
- 减少程序中反射的大量使用
- 做好熔断限流措施，对应用做好过载保护，比如阿里的sentinel限流熔断中间件
场景三：堆外内存OOM
Java对外内存（Direct Memory）OOM指的是Java直接使用的非堆内存（off-heap memory）耗尽导致的OutOfMemoryError。这部分内存主要用于Java NIO库，允许Java程序以更接近操作系统的方式管理内存，常用于高性能缓存、大型数据处理等场景
例如下面的代码，如何堆外内存太小，就会导致堆外内存的OOM：
// 分配大量直接内存导致OOM
import java.nio.ByteBuffer;
public class DirectMemoryOOM {
private static final int ONE_MB = 1024 * 1024;
public static void main(String[] args) {
int count = 1;
try {
while (true) {
ByteBuffer byteBuffer = ByteBuffer.allocateDirect(ONE_MB);
count++;
}
} catch (Exception e) {
System.out.println("Exception: instance created " + count);
throw e;
}
}
}
堆外内存的原因
- 分配过量的直接内存：程序中大量使用DirectByteBuffer等直接内存分配方式，而没有相应的释放机制，导致内存迅速耗尽，常见于NIO、Netty等相关组件。
- 内存泄露：如果分配的直接内存没有被及时释放（例如，ByteBuffer未被回收），就可能发生内存泄露。
- JVM对外内存限制设置不当：通过
-XX:MaxDirectMemorySize参数控制对外内存大小，如果设置过小，可能无法满足应用需求。
堆外内存OOM的解决方案
- 合理设置对外内存大小：根据应用的实际需求调整
-XX:MaxDirectMemorySize参数，给予足够的直接内存空间。 - 优化内存使用：减少不必要的直接内存分配，重用DirectByteBuffer等资源。
- 内存泄露排查：使用工具（如VisualVM、JProfiler等）定位和解决内存泄露问题。
- 代码优化：确保使用完直接内存后显式调用
sun.misc.Cleaner.clean()或通过其他机制释放内存。
场景一：堆内存OOM（也叫堆内存溢出）
这是最常见的OOM场景了，发生在JVM试图分配对象空间时，却发现剩余的堆内存不足以存储新对象。
例如我们执行下面的代码，就可以模拟出堆内存OOM的场景：
// 创建大量对象导致堆内存溢出
public class HeapOOM {
static class OOMObject {
// 假设这里有一些属性
}
public static void main(String[] args) {
List<OOMObject> list = new ArrayList<>();
while (true) {
list.add(new OOMObject()); // 不断创建对象并添加到list中
}
}
}那么当出现线上应用OOM场景时，该如何解决呢？
分析方法通常有两种：
- 类型一：在线分析，属于轻量级的分析：
- 类型二：离线分析，属于重量级的分析：
类型一：在线OOM分析：
在线分析Java OOM（内存溢出）问题，通常涉及到监控运行中的Java应用，捕获内存溢出时的信息，分析堆转储（Heap Dump）文件，以及利用一些工具和命令来辅助定位问题。下面是一套详细的分析流程和命令，帮助你在线分析和解决Java OOM问题：
1、启用JVM参数以捕获Heap Dump
在Java应用启动命令中加入以下JVM参数，以确保在发生OOM时能自动生成堆转储文件：
-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/path/to/heapdump.hprof这些参数的作用是：
-XX:+HeapDumpOnOutOfMemoryError：指示JVM在遇到OOM错误时生成堆转储文件。-XX:HeapDumpPath：指定堆转储文件的存储路径，可以自定义路径和文件名。
2、实时监控内存使用情况
使用jvisualvm或jconsole等工具可以实时监控Java应用的内存使用情况。这些工具可以帮助你了解内存消耗的趋势，从而预测和避免OOM的发生。
- JVisualVM：集成了多个JDK命令行工具，提供了可视化界面，可以监控内存使用、查看线程、分析堆等。
- JConsole：Java监控和管理控制台，用于对JVM中的内存、线程和类等进行监控。
3、分析Heap Dump文件
当应用抛出OOM并且根据上述设置生成了堆转储文件后，使用Heap Dump分析工具来分析这个文件。常用的工具有：
- Eclipse Memory Analyzer (MAT)：一个强大的Java堆分析工具，可以帮助识别内存泄露和查看内存消耗情况。
- VisualVM：除了监控功能外，也支持加载和分析Heap Dump文件。
在MAT中打开Heap Dump文件，主要关注以下几点：
- 查找内存中对象的分布，特别是占用内存最多的对象。
- 分析这些对象的引用链，确定是哪部分代码引起的内存泄漏或过度消耗。
- 检查ClassLoader，以确认是否有过多的类被加载导致的元空间（Metaspace）OOM。
4、使用命令行工具
JDK提供了一些命令行工具，如jmap，可以用来生成Heap Dump文件：
jmap -dump:live,format=b,file=heapdump.hprof <pid>其中<pid>是Java进程的ID。-dump:live选项表示只转储活动对象，可以减小Heap Dump文件的大小。
5、分析日志和异常信息
最后，不要忽视应用的日志和抛出的异常信息。OOM之前的日志可能会提供一些导致内存溢出的操作或业务逻辑的线索。
类型二：离线OOM分析，这个属于重量级分析
离线分析Java OOM（OutOfMemoryError）通常是在问题发生后，通过分析JVM生成的堆转储（Heap Dump）文件来进行。这个过程涉及到获取堆转储文件、使用分析工具进行深入分析和解读分析结果
1、获取Heap Dump文件
首先，确保你已经有了一个Heap Dump文件。这个文件可能是在JVM遇到OOM时自动生成的（如果启用了-XX:+HeapDumpOnOutOfMemoryError JVM参数），或者你可以在应用运行期间手动生成：
-
使用
jmap命令生成Heap Dump文件：jmap -dump:live,format=b,file=/path/to/heapdump.hprof <pid>其中
<pid>是Java进程的ID，/path/to/heapdump.hprof是你希望保存Heap Dump文件的位置。
2、使用Heap Dump分析工具
有了Heap Dump文件后，你需要使用专门的工具来进行分析。以下是一些常用的分析工具：
- Eclipse Memory Analyzer (MAT)：非常强大的内存分析工具，能帮助识别内存泄漏和查看内存消耗情况。
- VisualVM：提供了一个可视化界面，可以用来分析Heap Dump文件。
- JVisualVM：随JDK一起提供的工具，也支持加载Heap Dump文件进行分析。
3、分析Heap Dump文件
使用MAT（Eclipse Memory Analyzer）作为示例，分析流程如下：
- 打开Heap Dump文件：启动MAT并打开Heap Dump文件（.hprof）。
- 运行Leak Suspects Report：MAT可以自动生成一个内存泄漏报告（Leak Suspects Report），这个报告会指出可能的内存泄漏路径。
- 分析Dominators Tree：这个视图显示了占用最多内存的对象及其引用。通过它，你可以找到最大的内存消耗者。
- 查看Histogram：对象Histogram列出了所有对象的实例数和总大小，帮助你识别哪种类型的对象占用了最多的内存。
- 检查GC Roots：为了确定对象为什么没有被垃圾回收，可以查看对象到GC Roots的引用链。
- 分析引用链：通过分析对象的引用链，你可以确定是什么持有了这些对象的引用，导致它们无法被回收。
下面给大家提供一份Java应用上线前参考的的JVM配置（内存8G）,以后系统上线前可以先配置下JVM，不要啥都不配置就上线了
-Xms6g -Xmx6g （按不同容器，4G及以下建议为50%，6G以上，建议设置为70%）
-Xmn2g (以8G内存，年轻代可以设置为2G)
-XX:MetaspaceSize=256m
-XX:MaxMetaspaceSize=512m
-Xss256k
-XX:+UseG1GC
-XX:MaxGCPauseMillis=200
-XX:AutoBoxCacheMax=20000
-XX:+HeapDumpOnOutOfMemoryError （当JVM发生OOM时，自动生成DUMP文件）
-XX:HeapDumpPath=/usr/local/logs/gc/
-XX:ErrorFile=/usr/local/logs/gc/hs_err_%p.log （当JVM发生崩溃时，自动生成错误日志）
-XX:+PrintGCApplicationStoppedTime
-XX:+PrintGCDetails
-XX:+PrintGCDateStamps
-Xloggc:/usr/local/heap-dump/场景二：元空间（MetaSpace）OOM
什么是元空间？
Java元空间（Metaspace）是Java虚拟机（JVM）中用于存放类的元数据的区域，从Java 8开始引入，替代了之前的永久代（PermGen）
图中红色箭头所指就是元空间
元空间是方法区在HotSpot JVM 中的实现，方法区主要用于存储类的信息、常量池、方法数据、方法代码等。方法区逻辑上属于堆的一部分，但是为了与堆进行区分，通常又叫“非堆”。
元空间的本质和永久代类似，都是对JVM规范中方法区的实现。
不过元空间与永久代之间最大的区别在于：元空间并不在虚拟机中，而是使用本地内存。理论上取决于32位/64位系统可虚拟的内存大小，可见也不是无限制的，需要配置参数。
元空间(Metaspace) 垃圾回收，会对僵死的类及类加载器的垃圾回收会进行回收，元空间(Metaspace) 垃圾回收的时机是，在元数据使用达到“MaxMetaspaceSize”参数的设定值时进行。
元空间OOM的现象
JVM 在启动后或者某个时间点开始，MetaSpace 的已使用大小在持续增长，同时每次 GC 也无法释放，调大 MetaSpace 空间也无法彻底解决。
元空间OOM的核心原因：生成了大量动态类
比如：
- 使用大量动态生成类的框架（如某些ORM框架、动态代理技术、热部署工具等）
- 程序代码中大量使用反射，反射在大量使用时，因为使用缓存的原因，会导致ClassLoader和它引用的Class等对象不能被回收
例如下面的生成大量动态代理类的代码示例，则会导致元空间的OOM
// 使用CGLIB动态生成大量类导致元空间溢出
public class MetaspaceOOM {
public static void main(String[] args) {
while (true) {
Enhancer enhancer = new Enhancer();
enhancer.setSuperclass(OOMObject.class);
enhancer.setUseCache(false);
enhancer.setCallback(new MethodInterceptor() {
public Object intercept(Object obj, Method method, Object[] args, MethodProxy proxy) throws Throwable {
return proxy.invokeSuper(obj, args);
}
});
enhancer.create(); // 动态生成类并加载
}
}
static class OOMObject {
// 这里可以是一些业务方法
}
}
元空间(Metaspace) OOM 解决办法：
- 减少程序中反射的大量使用
- 做好熔断限流措施，对应用做好过载保护，比如阿里的sentinel限流熔断中间件
场景三：堆外内存OOM
Java对外内存（Direct Memory）OOM指的是Java直接使用的非堆内存（off-heap memory）耗尽导致的OutOfMemoryError。这部分内存主要用于Java NIO库，允许Java程序以更接近操作系统的方式管理内存，常用于高性能缓存、大型数据处理等场景
例如下面的代码，如何堆外内存太小，就会导致堆外内存的OOM：
// 分配大量直接内存导致OOM
import java.nio.ByteBuffer;
public class DirectMemoryOOM {
private static final int ONE_MB = 1024 * 1024;
public static void main(String[] args) {
int count = 1;
try {
while (true) {
ByteBuffer byteBuffer = ByteBuffer.allocateDirect(ONE_MB);
count++;
}
} catch (Exception e) {
System.out.println("Exception: instance created " + count);
throw e;
}
}
}
堆外内存的原因
- 分配过量的直接内存：程序中大量使用DirectByteBuffer等直接内存分配方式，而没有相应的释放机制，导致内存迅速耗尽，常见于NIO、Netty等相关组件。
- 内存泄露：如果分配的直接内存没有被及时释放（例如，ByteBuffer未被回收），就可能发生内存泄露。
- JVM对外内存限制设置不当：通过
-XX:MaxDirectMemorySize参数控制对外内存大小，如果设置过小，可能无法满足应用需求。
堆外内存OOM的解决方案
- 合理设置对外内存大小：根据应用的实际需求调整
-XX:MaxDirectMemorySize参数，给予足够的直接内存空间。 - 优化内存使用：减少不必要的直接内存分配，重用DirectByteBuffer等资源。
- 内存泄露排查：使用工具（如VisualVM、JProfiler等）定位和解决内存泄露问题。
- 代码优化：确保使用完直接内存后显式调用
sun.misc.Cleaner.clean()或通过其他机制释放内存。
关于JVM，年轻代（新生代）、老年代、永久代、minor gc(young gc)、major gc、full gc
不要急，先上图，这是jvm 堆内存结构图
仔细的你发现了 图中有些分数8/10和1/10，这是默认配置下各个代内存分配比例。
举个栗子：
假如总heap max分配1200M，那么年轻代占用1/3就是400M，老年代占2/3就是800M。
Eden占年轻代的8/10就是320M。Survivor占年轻代的2/10就是80M，from和to各占40M。

年轻代
也叫新生代，顾名思义，主要是用来存放新生的对象。新生代又细分为 Eden区、SurvivorFrom区、SurvivorTo区。
新创建的对象都会被分配到Eden区(如果该对象占用内存非常大，则直接分配到老年代区), 当Eden区内存不够的时候就会触发MinorGC（Survivor满不会引发MinorGC，而是将对象移动到老年代中），
在Minor GC开始的时候，对象只会存在于Eden区和Survivor from区，Survivor to区是空的。
Minor GC操作后，Eden区如果仍然存活（判断的标准是被引用了，通过GC root进行可达性判断）的对象，将会被移到Survivor To区。而From区中，对象在Survivor区中每熬过一次Minor GC，年龄就会+1岁，当年龄达到一定值(年龄阈值，可以通过-XX:MaxTenuringThreshold来设置，默认是15)的对象会被移动到年老代中，否则对象会被复制到“To”区。经过这次GC后，Eden区和From区已经被清空。
“From”区和“To”区互换角色，原Survivor To成为下一次GC时的Survivor From区, 总之，GC后，都会保证Survivor To区是空的。
奇怪为什么有 From和To，2块区域？
这就要说到新生代Minor GC的算法了：复制算法
把内存区域分为两块，每次使用一块，GC的时候把一块中的内容移动到另一块中，原始内存中的对象就可以被回收了，
优点是避免内存碎片。

老年代
随着Minor GC的持续进行，老年代中对象也会持续增长，导致老年代的空间也会不够用，最终会执行Major GC（MajorGC 的速度比 Minor GC 慢很多很多，据说10倍左右）。Major GC使用的算法是：标记清除（回收）算法或者标记压缩算法。
标记清除（回收）：1. 首先会从GC root进行遍历，把可达对象（存过的对象）打标记
2. 再从GC root二次遍历，将没有被打上标记的对象清除掉。
优点：老年代对象一般是比较稳定的，相比复制算法，不需要复制大量对象。之所以将所有对象扫描2次，看似比较消耗时间，其实不然，是节省了时间。举个栗子，数组 1,2,3,4,5,6。删除2,3,4，如果每次删除一个数字，那么5,6要移动3次，如果删除1次，那么5,6只需移动1次。
缺点：这种方式需要中断其他线程（STW），相比复制算法，可能产生内存碎片。
标记压缩：和标记清除算法基本相同，不同的就是，在清除完成之后，会把存活的对象向内存的一边进行压缩，这样就可以解决内存碎片问题。
当老年代也满了装不下的时候，就会抛出OOM（Out of Memory）异常。
永久代（元空间）
在Java8中，永久代已经被移除，被一个称为“元数据区”（元空间，Metaspace）的区域所取代。
值得注意的是：元空间并不在虚拟机中，而是使用本地内存（之前，永久代是在jvm中）。这样，解决了以前永久代的OOM问题，元数据和class对象存在永久代中，容易出现性能问题和内存溢出，毕竟是和老年代共享堆空间。java8后，永久代升级为元空间独立后，也降低了老年代GC的复杂度。
Visual GC插件
自己不妨写点代码，测试下上面说过的GC过程，通过Visual GC插件
Java VisualVM安装Visual GC插件
https://blog.csdn.net/yujianping_123/article/details/99549194
上面说到了minor gc 和major gc，那么看下full gc
Full GC
是清理整个堆空间—包括年轻代和老年代。
什么时候触发：
1. 调用System.gc
2. 方法区空间不足
2.老年代空间不足，包括：
• 新创建的对象都会被分配到Eden区，如果该对象占用内存非常大，则直接分配到老年代区，此时老年代空间不足
• 做minor gc操作前，发现要移动的空间（Eden区、From区向To区复制时，To区的内存空间不足）比老年代剩余空间要大，则触发full gc，而不是minor gc
• 等等
GC优化的本质，也是为什么分代的原因：减少GC次数和GC时间，避免全区扫描。