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

Posted 2021-04-17 java1234

转载自：

https://www.cnblogs.com/xdcat/p/12986781.html

堆体系结构

一个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

HotSpot虚拟机在1.8之后已经取消了永久代，改为元空间，类的元信息被存储在元空间中。元空间没有使用堆内存，而是与堆不相连的本地内存区域。所以，理论上系统可以使用的内存有多大，元空间就有多大，所以不会出现永久代存在时的内存溢出问题。

 

这项改造也是有必要的，永久代的调优是很困难的，虽然可以设置永久代的大小，但是很难确定一个合适的大小，因为其中的影响因素很多，比如类数量的多少、常量数量的多少等。永久代中的元数据的位置也会随着一次full GC发生移动，比较消耗虚拟机性能。同时，HotSpot虚拟机的每种类型的垃圾回收器都需要特殊处理永久代中的元数据。将元数据从永久代剥离出来，不仅实现了对元空间的无缝管理，还可以简化Full GC以及对以后的并发隔离类元数据等方面进行优化。

堆内存调优

在JDK1.7中

在JDK1.8中，元空间取代永久代。元空间和永久代的最大的区别是永久代使用的是JVM的堆内存，元空间不在虚拟机中，而是使用本机物理内存。默认清空下，元空间只受本地内存限制，类的元数据放入本地内存，字符串常量池和类型静态变量放入java堆，类的元数据的加载量不再受MaxPermSize控制，而是由系统实际的可用空间来控制。

-Xms：初始分配大小，默认为物理内存的1/64

-Xmx：最大分配内存，默认为物理内存的1/4

-XX:+PrintGCDetails：输出详细的GC处理日志

配置完Xms、Xmx后的输出结果

java.lang.OutOfMemoryError: Java heap space异常GC处理日志：

[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)

YoungGC

[GC (Allocation Failure)  内存分配失败

[PSYoungGen: 2045K->488K(2560K)] 2045K->781K(9728K), 0.0014360 secs] 

[GC类型:GC前young区的内存占用->GC后young区的内存占用(新生代的总内存)] GC前JVM堆内存占用->GC后JVM堆内存占用(JVM堆的总内存),GC耗时

[Times: user=0.00 sys=0.00, real=0.00 secs] 

[GC用户耗时，系统耗时，实际耗时]

 FullGC

[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]

什么是GC？

GC是分类收集算法，JVM在进行GC的时候并不是每次对三个区域一起回收，大部分时候是回收新生代。频繁收集Young区，较少收集Old区，基本不动元空间。GC按照回收的区域分成了：普通GC minor GC和全局GC Full GC

Minor GC：只针对新生代区域的GC，发生在新生代的垃圾收集，因为大多数JAVA对象存活率都不高，所以Minor GC的操作非常频繁，垃圾回收的速度比较快。

Full GC：指发生在老年代的垃圾收集操作，出现Full GC，经常会伴随至少一次的Minor GC（但不绝对）。Full GC的速度一般比Minor GC 慢10倍以上。

GC有四大算法：引用计数法、复制算法、标记清除、标记压缩。