【JVM】堆体系结构及其内存调优

堆体系结构

一个JVM实例只存在一个堆内存，堆内存的大小是可调节的。类加载器读取类文件后，需要把类、方法、常量、变量放在堆内存中，保存所有引用类型的真实信息，以方便执行器指向，堆内存分为三个部分：年轻代、老年代、永久代。

Java7之前，堆内存在逻辑上分为：年轻代、老年代、永久代。物理上分为：年轻代、老年代

 Java8：永久代 ---> 元空间

新生区是类的诞生、成长、消亡的区域。一个类在新生区产生，最后被垃圾回收器收集。新生区分为伊甸区和幸存者区。幸存者区分为幸存0区，幸存1区。

当伊甸区空间用完的时候，程序还需要创建对象，JVM的垃圾回收器将对伊甸区进行垃圾回收（Minor GC），将伊甸区中不再被其他对象引用的对象进行销毁，将剩余的对象移动到幸存0区。

若幸存0区（from区）满了，对幸存0区进行垃圾回收，将剩余的对象移动到幸存1区。如果幸存1区（to区）满了，再移动到养老区。

如果养老区满了，就产生了Major GC（Full GC），进行养老区的内存清理。如果执行了Full GC后依然无法进行对象的保存，就会产生OOM异常，OutOfMemoryError。

异常：java.lang.OutOfMemoryError: Java heap space

JVM堆内存不够，原因：

• JVM的堆内存设置的太小，可以调整-Xms、-Xmx
• 代码中创建了大量的大对象，并且长时间不能被垃圾回收器收集（存在被引用）

Minor GC的过程

Java堆从GC的角度可以细分为新生代（Eden区、from 存活区、to 存活区，空间比例8:1:1）和老年代（空间比例1:2）。

复制 ☞ 清空 ☞ 互换

1. eden、survivor from 复制到 survivor to，对象年龄+1。

当eden区满，触发第一次GC，存活对象拷贝到survivor from区。当eden区再次触发GC，会扫描eden和from，对这两个区进行垃圾回收，将存活的对象，复制到to区，对象年龄+1。（如果有对象年龄达到了老年的标准，拷贝到老年代，对象年龄+1）

2. 清空eden、survivor from

清空eden和survivor from中对象，此时from为。

3. survivor from 和 survivor to 互换

to区存在对象，变成下一次GC的from区，from区成为下一次GC的to区，部分对象会在form和to区域复制往来15次（JVM的MaxTenuringshold参数默认是15），如果最终还是存活，就存入老年代。

方法区和永久代

参考自博客：https://www.jianshu.com/p/66e4e64ff278

在JDK1.6及之前，运行时常量池是方法区的一个部分，同时方法区里面存储了类的元数据信息、静态变量、即时编译器编译后的代码（比如spring 使用IOC或者AOP创建bean时，或者使用cglib，反射的形式动态生成class信息等）等。在JDK1.7及以后，JVM已经将运行时常量池从方法区中移了出来，在JVM堆开辟了一块区域存放常量池。

方法区和堆都是各个线程共享的内存区域，方法区用于存储虚拟机加载的类信息、普通常量、静态常量、编译器编译后的代码等，虽然JVM规范将方法区描述为堆的一个逻辑部分，但它还有一个别名叫Non-Heap，目的是和堆分开。

方法区常被成为永久代，严格来说二者不同，只是用永久代来实现方法区而已，方法区和永久代的关系很像Java中接口和类的关系，类实现了接口，而永久代就是HotSpot虚拟机对虚拟机规范中方法区的一种实现方式。

永久代在JDK1.7之前有，是一个常驻内存区域，用于存放JDK自身携带的class、interface的元数据，也就是说它存储的是运行环境必须的类信息，被装在进此区域的数据是不会被垃圾回收器回收掉的，关闭jvm才会释放这个区域所占的内存。

HotSpot虚拟机中存在三种垃圾回收现象，minor GC、major GC和full GC。对新生代进行垃圾回收叫做minor GC，对老年代进行垃圾回收叫做major GC，同时对新生代、老年代和永久代进行垃圾回收叫做full GC。许多major GC是由minor GC触发的，所以很难将这两种垃圾回收区分开。major GC和full GC通常是等价的，收集整个GC堆。但因为HotSpot VM发展了这么多年，外界对各种名词的解读已经完全混乱了，当有人说“major GC”的时候一定要问清楚他想要指的是上面的full GC还是major GC。

元空间

参考自博客：https://www.jianshu.com/p/66e4e64ff278

[GC (Allocation Failure) [PSYoungGen: 2045K->488K(2560K)] 2045K->781K(9728K), 0.0014360 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] 
[GC (Allocation Failure) [PSYoungGen: 2534K->488K(2560K)] 2827K->1548K(9728K), 0.0008101 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] 
[GC (Allocation Failure) [PSYoungGen: 2171K->504K(2560K)] 4318K->3194K(9728K), 0.0006870 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] 
[Full GC (Ergonomics) [PSYoungGen: 2207K->0K(2560K)] [ParOldGen: 7037K->2826K(7168K)] 9245K->2826K(9728K), [Metaspace: 3454K->3454K(1056768K)], 0.0051352 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] 
[GC (Allocation Failure) [PSYoungGen: 0K->0K(2560K)] 5000K->5000K(9728K), 0.0003304 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] 
[GC (Allocation Failure) [PSYoungGen: 0K->0K(2560K)] 5000K->5000K(9728K), 0.0002962 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] 
[Full GC (Allocation Failure) [PSYoungGen: 0K->0K(2560K)] [ParOldGen: 5000K->3913K(7168K)] 5000K->3913K(9728K), [Metaspace: 3455K->3455K(1056768K)], 0.0028924 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] 
[GC (Allocation Failure) [PSYoungGen: 0K->0K(1536K)] 3913K->3913K(8704K), 0.0005099 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] 
[Full GC (Allocation Failure) [PSYoungGen: 0K->0K(1536K)] [ParOldGen: 3913K->3889K(7168K)] 3913K->3889K(8704K), [Metaspace: 3455K->3455K(1056768K)], 0.0072665 secs] [Times: user=0.06 sys=0.02, real=0.01 secs] 
Exception in thread "main" java.lang.OutOfMemoryError: Java heap space
    at java.util.Arrays.copyOf(Arrays.java:3332)
    at java.lang.AbstractStringBuilder.ensureCapacityInternal(AbstractStringBuilder.java:124)
    at java.lang.AbstractStringBuilder.append(AbstractStringBuilder.java:674)
    at java.lang.StringBuilder.append(StringBuilder.java:208)
    at day05JVM01.T2.main(T2.java:15)