JVM
java中的Heap（堆）是JVM所管理的最大的一块内存空间，主要用于存放各种类的实例对象。
由于Java堆是垃圾收集器管理的主要区域，因此也被称为“GC堆”
GC分为两种:Minor GC，Full GC(或者称为Major GC)
在Java中，堆被划分为两个不同的区域：年轻代(Young)、老年代(Tenured)。年轻代又被划分为三个区域：Eden、From Survivor、To Survivor。这样划分的目的是为了使JVM能够更好的管理堆内存中的对象，包括内存的分配以及回收。
堆大小=年轻代+老年代
年轻代 = eden space（新生代） + from survivor +to survivor
一、年轻代
1、年轻代用来存放新近创建的对象。大小随堆大小的增大和减小而相应的变化，默认值是保持堆大小的1/15，可以通过-Xmn参数设置年轻代为固定大小，也可以通过-XX:NewRatio来设置年轻代与老年代的大小比例。年轻代的特点是对象更新速度快，在短时间内产生大量的"死亡对象"。
2、年轻代的特点是产生大量的死亡对象，并且要产生连续可用的空间，所以使用复制清除算法和并行收集器进行垃圾回收，对年轻代的垃圾回收称作初级回收(minor gc)
3、初级回收将年轻代分为三个区域，一个新生代（eden），两个复活代(survivor)，应用程序只能使用一个新生代和复活代。当发生初级垃圾回收的时候，gc挂起程序，然后将新生代和复活代中的存活对象复制到另一个非活动的复活代中，然后一次性清除新生代和复活代。将原来的非活动复活代标记成为活动复活代。将在指定次数回收后仍然存活的对象移动到老年代中。初级回收后，得到一个空的可用的新生代
4、新生代几乎是所有Java对象出生的地方，即Java对象申请的内存以及存放都是在这个地方。Java中的大部分对象不需要长久存活，具有朝生夕灭的性质。当一个对象被判定为"死亡"的时候，GC就有责任来回收掉这部分对象的内存空间。新生代是GC收集垃圾的频繁区域。当对象在eden区出生后，在经过一次Minor GC后，如果对象还存活并且能够被另外一块Survivor区域所容纳。则使用复制算法将这些仍然存活的对象复制到另外一块Survivor区域中，然后清理所使用过的Eden和Survivor区域，并且将这些对象的年龄设置为1，以后对象在Survivor区每熬过一次Minor GC，就将对象的年龄加1，当对象的年龄到达某个值时(默认是15，可以通过参数-XX:MaxTenuringThreshold来设定)，这些对象就会成为老年代。但这也不是一定的，对于一些较大的对象(即需要分配一块较大的连续内存空间)则是直接进入到老年代。
5、JVM每次只会使用Eden和其中的一块Survivor来为对象服务，所以无论什么时候，总有一块Survivor区域是空闲着的。因此，新生代实际可用的内存空间为9/10(即90%)的新生代空间。
二、老年代
1、Full GC 是发生在老年代的垃圾收集动作，采用 标记-清除算法
2、现实的生活中，老年代的人通常会比新生代的人"早死"。堆内存中的老年代不同于这个，老年代的对象几乎个个都是在Survivor区域熬过来的，它们是不会那么容易就"死掉’'的。因此，Full GC发生的次数不会有Minor GC那么频繁，并且进行一次Full GC要比进行一次Minor GC的时间更长。另外，标记-清除算法收集垃圾的时候会产生许多内存碎片（即不连续的内存空间），此后需要为较大的对象分配内存时，若无法找到足够的连续的内存空间，就会提前触发一次GC的收集动作。
三、永久代
1、永久代用于存放静态文件，如java类，方法等。永久代对垃圾回收没有显著影响，但是有一些应用可能动态生成或者调用一些class，例如Hibernate等，在这种时候需要设置一个比较大的永久代空间来存放这些运行过程中新增的类。永久代大小通过-XX:MaxPermSize进行设置
2、在JAVA8中，永久代被彻底移除。取而代之的是另一块内存区域——元空间。 它可以通过-XX:MetaspaceSize和-XX:MaxMetaspaceSize来进行调整，当达到-XX:MetaspaceSize所指定的阈值后就会开始进行清理该区域。
如果本地空间的内存用尽了会收到java.lang.OutOfMemoryError:Metadata space 的错误信息，和永久代相关的JVM参数-XX:PermSize及-XX:MaxPermSize将会忽略掉。
参考地址：
1、https://gblog.sherlocky.com/java-xin-sheng-dai-lao-nian-dai/
2、https://blog.csdn.net/sted_zxz/article/details/72476673
3、https://blog.csdn.net/a754112602/article/details/81194373