15

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

 3 years ago
source link: http://www.cnblogs.com/xdcat/p/12986781.html
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.

堆体系结构

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

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

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

EZJfIz6.png!web

新生区是类的诞生、成长、消亡的区域。一个类在新生区产生，最后被垃圾回收器收集。新生区分为伊甸区和幸存者区。幸存者区分为幸存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）。

aaymqm3.png!web

复制 ☞ 清空 ☞ 互换

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才会释放这个区域所占的内存。

ZBV3AnZ.png!web

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中

UJJFJnn.png!web

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

AjAjemZ.png!web

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

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

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

zAFNBnN.png!web

配置完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有四大算法：引用计数法、复制算法、标记清除、标记压缩。


report

Recommend

About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK