堆体系结构
一个JVM实例只存在一个堆内存,堆内存的大小是可调节的。类加载器读取类文件后,需要把类、方法、常量、变量放在堆内存中,保存所有引用类型的真实信息,以方便执行器指向,堆内存分为三个部分:年轻代、老年代、永久代。
Java7之前,堆内存在逻辑上分为:年轻代、老年代、永久代。物理上分为:年轻代、老年代
Java8:永久代 ---> 元空间
![737b5052008f02d07a607f49377b6e72.png](https://i-blog.csdnimg.cn/blog_migrate/f7fc88e350a63e8fabb51169ccbcefc4.jpeg)
新生区是类的诞生、成长、消亡的区域。一个类在新生区产生,最后被垃圾回收器收集。新生区分为伊甸区和幸存者区。幸存者区分为幸存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)。
![41399e1f6f970fd997c8b4aa8d62ea16.png](https://i-blog.csdnimg.cn/blog_migrate/b0a7baf5f45b0de2b968dea6c5461466.jpeg)
复制 ☞ 清空 ☞ 互换
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才会释放这个区域所占的内存。
![77610f1e294fb8adc04120ba7864f179.png](https://i-blog.csdnimg.cn/blog_migrate/7ece55a9c59ca245ac72475af42c4a2a.jpeg)
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中
![104528ad0a8a3224b4851e3d9b667ed1.png](https://i-blog.csdnimg.cn/blog_migrate/07461a1a17d062e7bf0defd2354658b0.jpeg)
在JDK1.8中,元空间取代永久代。元空间和永久代的最大的区别是永久代使用的是JVM的堆内存,元空间不在虚拟机中,而是使用本机物理内存。默认清空下,元空间只受本地内存限制,类的元数据放入本地内存,字符串常量池和类型静态变量放入java堆,类的元数据的加载量不再受MaxPermSize控制,而是由系统实际的可用空间来控制。
![0dcc200439029d46016e3504e502fae2.png](https://i-blog.csdnimg.cn/blog_migrate/777e5f9bc356dd41e53bd95f59d91e4c.jpeg)
-Xms:初始分配大小,默认为物理内存的1/64
-Xmx:最大分配内存,默认为物理内存的1/4
-XX:+PrintGCDetails:输出详细的GC处理日志
![048ecaa410005bbd235c6bc54d15c87e.png](https://i-blog.csdnimg.cn/blog_migrate/6239bb6fc6b706f5551148bc0d23c1e3.jpeg)
配置完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有四大算法:引用计数法、复制算法、标记清除、标记压缩。