专栏首页ImportSourceJVM内存分配担保机制

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),作者:贺卓凡

原文出处及转载信息见文内详细说明,如有侵权,请联系 yunjia_community@tencent.com 删除。

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

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

我来说两句

0 条评论
登录 后参与评论

相关文章

  • 读懂一行Full GC日志(回复JVM内存分配担保机制一文中 Mr/Mrs Xxx 在留言区提出的问题)

    回复JVM内存分配担保机制一文中 Mr/Mrs Xxx 在留言区提出的问题: “请问分配3M的时候,怎么还发生了full gc?” 回复如下: 发生Full ...

    ImportSource
  • 性能优化|JVM内存分配机制

    了解jvm的同学应该都知道,堆其实是分为新老年代的,这主要是为了进行垃圾回收而设计的一种结构

    AI码师
  • 性能优化|JVM内存分配机制2

    jvm在每次minor gc之前,都会计算老年代的剩余可用空间,如果可用空间小于年轻代里面所有对象之和,如果没有配置担保参数(“-XX:-HandlePromo...

    AI码师
  • jvm空间分配担保怎么回事?

    jvm发生gc之前,先检查老年代最大可用的连续空间是否大于新生代所有对象总空间。

    逍遥壮士
  • JVM内存分配机制之栈上分配与TLAB的区别

    在java开发中,我们普遍认知中,new出的对象是直接分配到堆空间中,而实际情况并非如此,其实大家伙可以思考一下,无论方法的生命周期长与短,只要new的对象就存...

    黎明大大
  • JVM-09自动内存管理机制【内存分配和回收策略】

    大多数情况下,对象在新生代的eden区中分配,当eden区没有足够的空间进行分配时,虚拟机将进行一次Minor GC。

    小小工匠
  • JVM GC 那些事(二)- 堆上的内存分配机制

    前一篇文章JVM GC 那些事(一)- JVM 运行时内存划分介绍了 JVM 运行时的内存划分情况。本文将介绍 JVM GC “主战场” 堆上的内存分配机制。

    codingforfun
  • JVM的内存管理机制

    对于C、C++程序员来说,在内存管理领域,他们既拥有每一个对象的“所有权”,又担负着每一个对象生命开始到终结的维护责任。

    butterfly100
  • JVM内存分配与回收

    大多数情况下,对象在新生代中 Eden 区分配。当 Eden 区没有足够空间进行分配时,虚拟机将发起一次Minor GC。我们来进行实际测试一下。

    爱撸猫的杰
  • JVM内存模型及内存分配过程

    Java架构师历程
  • 深入理解JVM之JVM内存区域与内存分配

    在学习jvm的内存分配的时候,看到的这篇博客,该博客对jvm的内存分配总结的很好,同时也利用jvm的内存模型解释了java程序中有关参数传递的问题。

    哲洛不闹
  • JVM - 怎么保证堆内存分配的线程安全(TLAB)

    常见的解决办法就是CAS,失败重试,但是每次线程申请内存的时候都进行CAS,在并发高的情况下,会影响性能。 所以HotSpot虚拟机中采用TLAB的方法进行内...

    夹胡碰
  • JVM 运行时的内存分配

      首先我们必须要知道的是 Java 是跨平台的。而它之所以跨平台就是因为 JVM 不是跨平台的。JVM 建立了 Java 程序和操作系统之间的桥梁,JVM 是...

    IT可乐
  • JVM笔记-内存分配策略

    Java 技术体系的自动内存管理,最根本的目标就是解决两个问题:「自动化」地给对象分配、回收内存空间。

    WriteOnRead
  • JVM系列一:JVM内存组成及分配

    java内存组成介绍:堆(Heap)和非堆(Non-heap)内存 按照官方的说法:“Java 虚拟机具有一个堆,堆是运行时数据区域,所有类实例和...

    lyb-geek
  • [JVM] JVM自动内存管理机制(一)

    文本主要就JVM结构和字节码文件,进行分析来展开JVM的学习,后续系列文章会从JVM的多个方面的进行知识总结。

    架构探险之道
  • Memcached内存机制Memcached特点内存分配机制 - SlabAllocation内存使用机制 - LRU(Least Recently Used)优化思路

    Memcached特点 协议简单,基于文本行的协议 基于Libevent的时间处理 内置内存存储方式 分布式缓存服务器(采用一致性哈希算法实现的客户端分布式,而...

    Clive
  • JVM(2): 逃逸分析和内存分配

    我们都知道Java对象都是分配在在堆上的,在过往的认识中,一直是以这样的方式存在的,但是从Java7开始支持对象的栈分配和逃逸分析机制。

    yiduwangkai
  • Android | App内存优化 之 JVM & Android内存管理机制

    计数器的值代表着下一条需要执行的字节码指令,!!! 字节码解释器工作时, 就是通过改变这个计数器的值来选取下一条需要执行的字节码指令,!!!! 分支、循环...

    凌川江雪

扫码关注云+社区

领取腾讯云代金券