JVM内存分配担保机制

在现实社会中,借款会指定担保人,就是当借款人还不起钱,就由担保人来还钱。

在JVM的内存分配时,也有这样的内存分配担保机制。就是当在新生代无法分配内存的时候,把新生代的对象转移到老生代,然后把新对象放入腾空的新生代。

现在假设,我们的新生代分为三个区域,分别为eden space,from space和to space。

现在是尝试分配三个2MB的对象和一个4MB的对象,然后我们通过JVM参数 -Xms20M、-Xmx20M、-Xmn10M 把Java堆大小设置为20MB,不可扩展。

其中10M分配给新生代,另外10M分配给老生代。

然后我们通过-XX:SurvivorRatio=8来分配新生代各区的比例,设置为8,表示eden与一个survivor区的空间比例为8:1。

图1 新生代内存分配

JVM参数配置:

-Xms20M -Xmx20M -Xmn10M -XX:+PrintGCDetails -XX:SurvivorRatio=8 -XX:+UseSerialGC

这里我们先手动指定垃圾收集器为客户端模式下的Serial+Serial Old的收集器组合进行内存回收。

由于不同的收集器的收集机制不同,为了呈现出内存分配的担保效果,我们这里需要手动指定为Serial+Serial Old模式。

另外担保机制在JDK1.5以及之前版本中默认是关闭的,需要通过HandlePromotionFailure手动指定,JDK1.6之后就默认开启。这里我们使用的是JDK1.8,所以不用再手动去开启担保机制。

下面我们新建四个byte数组,前三个分别为2MB大小的内存分配,第四个是4MB的内存分配。代码如下:

然后运行程序,看看GC日志:

[GC (Allocation Failure) [DefNew: 7836K->472K(9216K), 0.0120087 secs] 7836K->6616K(19456K), 0.0123203 secs] [Times: user=0.01 sys=0.01, real=0.01 secs]

Heap

def new generation total 9216K, used 4732K [0x00000007bec00000, 0x00000007bf600000, 0x00000007bf600000)

eden space 8192K, 52% used [0x00000007bec00000, 0x00000007bf0290f0, 0x00000007bf400000)

from space 1024K, 46% used [0x00000007bf500000, 0x00000007bf576018, 0x00000007bf600000)

to space 1024K, 0% used [0x00000007bf400000, 0x00000007bf400000, 0x00000007bf500000)

tenured generation total 10240K, used 6144K [0x00000007bf600000, 0x00000007c0000000, 0x00000007c0000000)

the space 10240K, 60% used [0x00000007bf600000, 0x00000007bfc00030, 0x00000007bfc00200, 0x00000007c0000000)

Metaspace used 3160K, capacity 4494K, committed 4864K, reserved 1056768K

class space used 341K, capacity 386K, committed 512K, reserved 1048576K

通过GC日志我们发现在分配allocation4的时候,发生了一次Minor GC,让新生代从7836K变为了472K,但是你发现整个堆的占用并没有多少变化。这是因为前面三个2MB的对象都还存活着,所以回收器并没有找到可回收的对象。但为什么会出现这次GC呢?

图2 正常流程把前三个对象放入了新生代Eden区

如果你算一笔账就知道了,前面三个对象2MB+2MB+2MB=6MB

虚拟机分配内存优先会分配到新生代的eden space,通过图1我们知道新生代可用内存一共只有9216KB,现在新生代已经被用去了6MB,还剩下9216KB-6144KB=3072KB,然而第四个对象是4MB,显然在新生代已经装不下了。

图3 第四个对象此时无法放入Eden区

于是发生了一次Minor GC!

而且本次GC期间,虚拟机发现eden space的三个对象(6MB)又无法全部放入Survivor空间(Survivor可用内存只有1MB)。

这时候该怎么办呢?第四个对象还要不要分配呢?

此时,JVM就启动了内存分配的担保机制,把这6MB的三个对象直接转移到了老年代。

此时就把新生代的空间腾出来了,然后把第四个对象(4MB)放入了Eden区中,所以你看到的结果是4096/8192=0.5,也就是约50%:

eden space 8192K, 52% used [0x00000007bec00000, 0x00000007bf0290f0, 0x00000007bf400000)

老年代则被占用了6MB,也就是前三个对象,1024*2*3=6144KB,6144KB/10240KB=0.6也就是60%:

the space 10240K, 60% used [0x00000007bf600000, 0x00000007bfc00030, 0x00000007bfc00200, 0x00000007c0000000)

图4:担保后,allocation4放入到新生代eden区

图5:担保后,之前在新生代的三个对象转移到了老生代

服务端模式下的担保机制实现

上面我们演示的在客户端模式(Serial+Serial Old)的场景下的结果,接下来我们使用服务端模式(Parallel Scavenge+Serial Old的组合)来看看担保机制的实现。

修改GC组合为:-XX:+UseParallelGC

然后我们运行程序看看GC日志。

  • 第四个对象是4MB的情况下:

[GC (Allocation Failure) [PSYoungGen: 6156K->592K(9216K)] 6156K->4696K(19456K), 0.0032059 secs] [Times: user=0.01 sys=0.01, real=0.01 secs]

Heap

PSYoungGen total 9216K, used 7057K [0x00000007bf600000, 0x00000007c0000000, 0x00000007c0000000)

eden space 8192K, 78% used [0x00000007bf600000,0x00000007bfc505f8,0x00000007bfe00000)

from space 1024K, 57% used [0x00000007bfe00000,0x00000007bfe94010,0x00000007bff00000)

to space 1024K, 0% used [0x00000007bff00000,0x00000007bff00000,0x00000007c0000000)

ParOldGen total 10240K, used 4104K [0x00000007bec00000, 0x00000007bf600000, 0x00000007bf600000)

object space 10240K, 40% used [0x00000007bec00000,0x00000007bf002020,0x00000007bf600000)

Metaspace used 3299K, capacity 4494K, committed 4864K, reserved 1056768K

class space used 357K, capacity 386K, committed 512K, reserved 1048576K

  • 第四个对象是3MB的情况下:

[GC (Allocation Failure) [PSYoungGen: 8192K->544K(9216K)] 8192K->6688K(19456K), 0.0052943 secs] [Times: user=0.01 sys=0.00, real=0.00 secs]

[Full GC (Ergonomics) [PSYoungGen: 544K->0K(9216K)] [ParOldGen: 6144K->6627K(10240K)] 6688K->6627K(19456K), [Metaspace: 3286K->3286K(1056768K)], 0.0063048 secs] [Times: user=0.01 sys=0.00, real=0.01 secs]

Heap

PSYoungGen total 9216K, used 3238K [0x00000007bf600000, 0x00000007c0000000, 0x00000007c0000000)

eden space 8192K, 39% used [0x00000007bf600000,0x00000007bf929918,0x00000007bfe00000)

from space 1024K, 0% used [0x00000007bfe00000,0x00000007bfe00000,0x00000007bff00000)

to space 1024K, 0% used [0x00000007bff00000,0x00000007bff00000,0x00000007c0000000)

ParOldGen total 10240K, used 6627K [0x00000007bec00000, 0x00000007bf600000, 0x00000007bf600000)

object space 10240K, 64% used [0x00000007bec00000,0x00000007bf278f70,0x00000007bf600000)

Metaspace used 3294K, capacity 4494K, committed 4864K, reserved 1056768K

class space used 356K, capacity 386K, committed 512K, reserved 1048576K

发现当我们使用Server模式下的ParallelGC收集器组合(Parallel Scavenge+Serial Old的组合)下,担保机制的实现和之前的Client模式下(SerialGC收集器组合)有所变化。在GC前还会进行一次判断,如果要分配的内存>=Eden区大小的一半,那么会直接把要分配的内存放入老年代中。否则才会进入担保机制。

这里我们的第四个对象是4MB的时候,也就是(1024KB*4)/8192KB=0.5,刚好一半,于是就这第四个对象分配到了老年代。

第二次,我们把第四个对象由4MB,改为3MB,此时3MB/8192KB=0.37,显然不到一半,此时发现3MB还是无法放入,那么就执行担保机制,把前三个对象转移到老生代,然后把第四个对象(3MB)放入eden区。

总结

内存分配是在JVM在内存分配的时候,新生代内存不足时,把新生代的存活的对象搬到老生代,然后新生代腾出来的空间用于为分配给最新的对象。这里老生代是担保人。在不同的GC机制下,也就是不同垃圾回收器组合下,担保机制也略有不同。在Serial+Serial Old的情况下,发现放不下就直接启动担保机制;在Parallel Scavenge+Serial Old的情况下,却是先要去判断一下要分配的内存是不是>=Eden区大小的一半,如果是那么直接把该对象放入老生代,否则才会启动担保机制。

原文发布于微信公众号 - ImportSource(importsource)

原文发表时间:2017-12-10

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏salesforce零基础学习

salesforce 零基础学习(五十四)常见异常友好消息提示

异常或者error code汇总:https://developer.salesforce.com/docs/atlas.en-us.api.meta/api/...

1857
来自专栏流媒体人生

ATL源码学习4---TearOff接口支持

    http://download.csdn.net/source/1687116

882
来自专栏本立2道生

Win32对话框程序(2)

接着Win32对话框程序(1)来写 ,解决遗留的问题,即理解函数及其调用关系。文章中有些地方是自己的推断,因此肯定有叙述不准确甚至错误的地方,请指正,感谢~ 

1653
来自专栏石奈子的Java之路

原 荐 JVM笔记整理

2083
来自专栏JAVA高级架构

垃圾回收算法与 JVM 垃圾回收器综述

我们常说的垃圾回收算法可以分为两部分:对象的查找算法与真正的回收方法。不同回收器的实现细节各有不同,但总的来说基本所有的回收器都会关注如下两个方面:找出所有的存...

4168
来自专栏大大的微笑

JVM之垃圾回收

对象是否存活: ①.引用计数算法: 描述:每个对象有一个引用计数属性,新增一个引用时计数加1,引用释放时计数减1,计数为0时可以回收. 优势:简单高效...

2607
来自专栏Java架构师历程

聊聊jvm内存模型及垃圾回收算法

其中New和Tenured属于堆内存,堆内存会从JVM启动参数(-Xmx:3G)指定的内存中分配,Perm不属于堆内存,有虚拟机直接分配,但可以通过-XX:Pe...

1454
来自专栏码匠的流水账

频繁产生对象造成gc时间过长案例分析

gc时间过长,平均gc pause的时间要将近4秒,有13%的gc超过10秒,太可怕了,部分gc日志如下:

1541
来自专栏我的博客

Egret语法DataGroup使用案例

class Main extends egret.DisplayObjectContainer{ public constructor() { ...

3796
来自专栏张善友的专栏

Mono 3 的默认Gc是Sgen

Mono 3现在是默认 GC是SGen 垃圾回收器,垃圾回收器几个性能和扩展性方面的改进,以更好地利用多核处理器硬件。SGen 已移植到 Windows 和 M...

27210

扫码关注云+社区