理解JVM(4)- 堆内存的分代管理

前一篇从整体上了解了一下JVM的运行时数据区,它由线程私有的栈内存线程共享的堆内存、方法区组成。本章节将详细了解一下堆内存又被分为哪些区域,或者说JVM是如何把对象分配到这些区域上的

JVM根据对象在内存中存活时间的长短,把堆内存分为新生代(包括一个Eden区、两个Survivor区)和老年代(Tenured或Old)。Perm代(永久代,Java 8开始被“元空间”取代)属于方法区了,而且仅在Full GC时被回收。大致如下图


Heap Generation

为对象分配空间,就是把一块确定大小的内存从堆中划分出来(有一种例外情况,就是有可能经过JIT优化编译后,对象被拆分成标量类型从而变成了栈上分配)。新创建的对象主要分配在新生代的Eden区上,如果JVM启动了本地线程分配缓冲(TLAB,Thread Local Allocation Buffer),则对象将按线程优先分配在TLAB上,此区域仍然位于新生代的Eden区内。

关于TLAB

创建对象需要从堆中划分出一块确定大小的区域,那分配内存就是把指针从可用空闲区域挪动一段与对象大小相等的距离。而对象的创建是很频繁的行为,在并发情况并不是线程安全的,可能出现在给对象A分配内存,指针还没来得及修改,对象B又同时使用了原来的指针来分配内存的情况。为了解决这个问题,一个可行的方案就是TLAB,即把内存分配的动作按照线程划分在不同的空间内进行,即每个线程在堆内预先分配一小块内存,称为“本地线程分配缓冲”。哪个线程要给对象分配内存,就在自己的TLAB上分配,当自己的TLAB用完再去申请新的TLAB,这个时候再去进行指针的同步锁定,从而减小开销。


TLAB

对象优先分配在Eden区

大部分情况下,对象会在新生代的Eden区中分配空间,当Eden区没有足够大小的连续空间来分配给新创建的对象时,JVM将会触发一次Minor GC

HotSpot的开发人员将GC执行分为比较模糊的三种模型:

  • Minor GC:发生在新生代,回收新生代中的垃圾,速度很快但也很频繁
  • Major GC:发生在老年代,比Minor GC慢10倍以上;通常会伴随一次Minor GC
  • Full GC:回收所有区域,包括堆内存、方法区(Java 8之前的“永久代”,Java 8开始取代永久代的“元空间”)和直接内存,速度慢,工作线程的暂停时间长

绝大多数对象所占的内存空间会在Minor GC中被回收(IBM公司的专门研究表明,新生代中的对象98%是“朝生夕死”的),那些存活下来的对象会被分配到某一个Survivor(幸存区,名字也很形象),但如果Survivor的空间不足以安置存活对象的话,JVM会通过“空间分配担保机制”提前转移这些对象到老年代去。

  1. 新生代中为什么有两个Survivor区?为什么每次只使用其中一个呢?

这跟新生代采用的垃圾回收算法有关,新生代用的是“复制”算法,该算法的特点是牺牲一定的空间成本,来换取高效率的垃圾回收,此算法不会产生内存碎片,回收后内存比较规整。关于各回收算法的细节,下一个章节再介绍,这里就不累赘了。

  1. “空间分配担保”是什么?

在发生Minor GC之前,JVM会先检查老年代最大可用的连续空间是否大于新生代所有对象总空间,如果这个条件成立,那么Minor GC可以确保是安全的。如果不成立,则JVM会查看HandlePromotionFailure设置值是否允许担保失败。若允许,那么会继续检查老年代最大可用的连续空间是否大于历次晋升到老年代对象的平均大小,如果大于,将尝试进行一次Minor GC,尽管这次Minor GC是有风险的;如果小于,或者HandlePromotionFailure设置不允许冒险,那这时要改为进行一次Full GC。

下面这个示例代码演示了Survivor区空间不足,对象通过分配担保机制被提前转移到老年代去。Debug执行三条对象创建语句,通过JDK自带的Java VisualVM工具jvisualvm(同时安装Visual GC插件),可以直观的看到各个内存区的变化情况。

/**
 *  -Xms90m -Xmx90m -XX:+UseParNewGC
 *
 * 固定堆大小:90m
 *     - Young Gen: 1/3 * 90 = 30m (默认 Tenured / Young = 2)
 *         - Survivor * 2 : 1/10 * 30 = 3m * 2 (两个Survivor,默认 Eden / Survivor = 8)
 *         - Eden: 8/10 * 30 = 24m
 *     - Tenured: 2/3 * 90 = 60m  (默认 Tenured / Young = 2)
 */
public class HandlePromotionDemo {

    public static void main(String[] args) {
        byte[] obj1 = new byte[1024 * 1024 * 2];
        byte[] obj2 = new byte[1024 * 1024 * 10];
        byte[] obj3 = new byte[1024 * 1024 * 20];
    }

}

以下三个截图分别展示了三个对象依次创建后的内存各区情况


第一行代码执行完,2MB的对象obj1创建成功后,Eden消耗2.480MB,这里大于obj1的大小是因为VisualVM GC监测工具自身也会创建一些临时对象。不管如何,还是可以直观的看到obj1分配到了Eden区
第二行代码执行完,10MB的对象obj2创建成功后,Eden消耗的空间增加到了12.480MB,注意图中圈出来的陡升区域,obj2就是在那一刻创建成功的
第三行代码执行完,20MB的对象obj3创建成功后,Eden消耗的空间变成了20MB。在创建obj3之前,JVM检测到容量为24MB的Eden已经消耗了12.480MB,剩下的空间不足以安置obj3,所以触发Minor GC,obj1被移到幸存区S1,但S1不能再容纳大对象obj2,通过“空间分配担保”,obj2被提前转移到老年代。此时被清空了的Eden区域可以用来分配新对象obj3了,创建成功后,Eden消耗了20MB即为obj3的大小

大对象直接进去老年代

大对象就是那些需要大量连续内存空间的对象,比如数组及很长的字符串。过多的大对象容易导致当内存空间仍然还有不少时就会提前触发GC以获取足够连续的空间来分配给这些大对象。
虚拟机提供了一个参数-XX:PretenureSizeThreshold,那些大于这个参数值的对象将直接在老年代分配,避免在Eden区和两个Survivor区之间发生大量的内存复制(新生代采用的是“复制”垃圾回收算法)。

下面这个示例代码指定一个Survivor区域容量大小为4MB,同时设置-XX:PretenureSizeThreshold=3145728,即3MB,之后创建一个略大于3MB的对象。运行此程序后,从VisualVM GC中可以看到此对象被分配到了老年代。

/**
 * -Xmn16m -Xms30m -Xmx30m -XX:SurvivorRatio=2 -XX:+UseParNewGC -XX:PretenureSizeThreshold=3145728 -XX:-UseTLAB
 *
 * Fixed Heap: 30MB
 *    - Survivor * 2: 4MB * 2
 *    - Eden: 8MB
 *    - Tenured: 14MB 
 */
public class BiggerThanPretenureSizeThresholdObjToOld {

    public static void main(String[] args) throws Exception {
        System.gc(); // 尝试清除由监测工具生成的临时对象
        Thread.sleep(10000L);

        byte[] obj = new byte[1024 * 1024 * 3 + 1];
        boolean flag = true;
        while(flag) {
            Thread.yield();
        }
    }

}
对象obj创建成功后,被分配在老年代

对于极端情况,参数-XX:PretenureSizeThreshold未设置,而对象大于Eden空间的话,则同样直接在老年代分配空间

长期存活的对象会被晋升到老年代

虚拟机在进行内存回收的时候,为了能够识别哪些对象应该继续留在新生代(某一个Survivor区)、哪些对象应该被晋升(转移)到老年代,它给每个对象定义了一个对象年龄(Age)计数器。所有在新生代出生的对象,年龄可以认为是0,此时的数值没有任何意义。当对象经过第一次Minor GC后任然存活,并且Survivor有足够的空间来容纳它的话,对象被顺利转移到Survivor中,此时对象开始拥有实际意义的年龄,为1岁。在此之后,Survivor中的对象每“熬过”一次Minor GC,年龄就会增加1岁,当达到一定的年龄阈值(默认是15岁,可通过参数-XX:MaxTenuringThreshold设置),对象就会被晋升到老年代中。老年代中的对象就没有年龄的意义了。

下面我们通过一个示例来演示一下:对象年龄达到阈值后被晋升到老年代。设置参数,固定堆大小为90MB,新生代45MB,其中Eden和Survivor各占15MB、15MB、15MB,年龄阈值为2岁。

/**
 *  -XX:+PrintGCDetails -Xmn45m -Xms90m -Xmx90m -XX:SurvivorRatio=1 -XX:MaxTenuringThreshold=2 -XX:+UseParNewGC
 *
 *  Fixed Heap: 90M
 *      - Survivor *2: 15M *2
 *      - Edeb: 15M
 *      - Tenured(Old): 45M
 */
public class AgeOlderThanTenuringThresholdObjToOld {

    public static void main(String[] args) throws Exception {
        System.gc(); //尝试清除由监测工具生成的临时对象

        byte[] obj1 = new byte[1024 * 1024 * 2]; //执行完这一行之后各区使用情况: Eden[obj1]: 2/15, S0: 0/15, S1: 0/15, Old: 0/45
        byte[] obj2 = new byte[1024 * 1024 * 2]; //执行完这一行之后各区使用情况: Eden[obj1,obj2]: 4/15, S0: 0/15, S1: 0/15, Old: 0/45
        byte[] obj3 = new byte[1024 * 1024 * 12]; //对象obj3创建成功之前,虚拟机检测到Eden剩余空间(15-4=11)不足以分配给obj3,因此触发第一次Minor GC来释放空间给obj3,obj1和obj2晋升到幸存区,年龄为1,各区使用情况: Eden[obj3]: 12/15, S0: 0/15, S1[obj1(age=1),obj2(age=1)]: 4/15, Old: 0/45
        obj3 = null; //obj3不再有任何引用关联,下次GC的时候将会被回收
        byte[] obj4 = new byte[1024 * 1024 * 4]; //对象obj4创建成功之前,虚拟机检测到Eden剩余空间(15-12=3)不足以分配给obj4,因此触发第二次Minor GC来释放空间给obj4,这次GC中obj3会被回收,之后各区使用情况: Eden[obj4]: 4/15, S0:[obj1(age=2),obj2(age=2)]: 4/15, S1: 0/15, Old: 0/45
        byte[] obj5 = new byte[1024 * 1024 * 12]; //对象obj5创建成功之前,虚拟机检测到Eden剩余空间(15-4=11)不足以分配给obj5,因此触发第三次MinorGC来释放空间给obj5,这次GC中由于obj1,obj2的年龄都到达了阈值2岁,所以这两个对象将被晋升到老年代,之后各区使用情况:Eden[obj5]: 12/15, S0: 0/15, S1[obj4(age=1)]: 4/15, Old[obj1,obj2]: 4/45
    }

}

Debug逐行执行上面5个对象的创建语句,每个对象创建成功后的各区使用情况如下各图:

对象obj1创建成功之后各区使用情况: Eden[obj1]: 2/15, S0: 0/15, S1: 0/15, Old: 0/45
对象obj2创建之后各区使用情况: Eden[obj1,obj2]: 4/15, S0: 0/15, S1: 0/15, Old: 0/45
对象obj3创建成功之前,虚拟机检测到Eden剩余空间(15-4=11)不足以分配给obj3,因此触发第一次Minor GC来释放空间给obj3,obj1和obj2晋升到幸存区,年龄为1,各区使用情况: Eden[obj3]: 12/15, S0: 0/15, S1[obj1(age=1),obj2(age=1)]: 4/15, Old: 0/45
对象obj4创建成功之前,虚拟机检测到Eden剩余空间(15-12=3)不足以分配给obj4,因此触发第二次Minor GC来释放空间给obj4,这次GC中obj3会被回收,之后各区使用情况: Eden[obj4]: 4/15, S0:[obj1(age=2),obj2(age=2)]: 4/15, S1: 0/15, Old: 0/45
对象obj5创建成功之前,虚拟机检测到Eden剩余空间(15-4=11)不足以分配给obj5,因此触发第三次MinorGC来释放空间给obj5,这次GC中由于obj1,obj2的年龄都到达了阈值2岁,所以这两个对象将被晋升到老年代,之后各区使用情况:Eden[obj5]: 12/15, S0: 0/15, S1[obj4(age=1)]: 4/15, Old[obj1,obj2]: 4/45

动态对象年龄判断

虚拟机并不是永远的要等到对象年龄达到阈值后才能晋升到老年代,当Survivor中相同年龄(比如N)的所有对象的大小总和大于Survivor的一半的时候,那些年龄大于等于N所有对象将会直接提前进入老年代。

示例代码如下:固定堆大小为90MB,新生代45MB,其中Eden和Survivor各占15MB、15MB、15MB,未设置最大年龄阈值,使用默认值15

/**
 *  -XX:+PrintGCDetails -Xmn45m -Xms90m -Xmx90m -XX:SurvivorRatio=1 -XX:+UseParNewGC
 *
 *  Fixed Heap: 90M
 *      - Survivor *2: 15M *2
 *      - Edeb: 15M
 *      - Tenured(Old): 45M
 */
public class DynamicAge {

    public static void main(String[] args) throws Exception {
        System.gc(); //尝试清除由监测工具生成的临时对象

        byte[] obj1 = new byte[1024 * 1024 * 4]; //执行完这一行之后各区使用情况: Eden[obj1]: 4/15, S0: 0/15, S1: 0/15, Old: 0/45
        byte[] obj2 = new byte[1024 * 1024 * 4]; //执行完这一行之后各区使用情况: Eden[obj1,obj2]: 8/15, S0: 0/15, S1: 0/15, Old: 0/45
        byte[] obj3 = new byte[1024 * 1024 * 12]; //对象obj3创建成功之前,虚拟机检测到Eden剩余空间(15-8=7)不足以分配给obj3,因此触发第一次Minor GC来释放空间给obj3,obj1和obj2晋升到幸存区,年龄为1,各区使用情况: Eden[obj3]: 12/15, S0: 0/15, S1[obj1(age=1),obj2(age=1)]: 8/15, Old: 0/45
        obj3 = null; //obj3不再有任何引用关联,下次GC的时候将会被回收
        byte[] obj4 = new byte[1024 * 1024 * 4]; //对象obj4创建成功之前,虚拟机检测到Eden剩余空间(15-12=3)不足以分配给obj4,因此触发第二次MinorGC来释放空间给obj4,这次GC中由于Survivor区中的obj1和obj2的大小之和8超过了Survivor大小15的一半,所以这两个对象将被提前晋升到老年代,而对象obj3由于没有任何引用,直接被回收了,之后各区使用情况: Eden[obj4]: 4/15, S0: 0/15, S1: 0/15, Old[obj1,obj2]: 8/45
     
    }

}

Debug逐行执行上面4个对象的创建语句,每个对象创建成功后的各区使用情况如下各图:

对象obj1创建之后各区使用情况: Eden[obj1]: 4/15, S0: 0/15, S1: 0/15, Old: 0/45

对象obj2创建之后各区使用情况: Eden[obj1,obj2]: 8/15, S0: 0/15, S1: 0/15, Old: 0/45
对象obj3创建成功之前,虚拟机检测到Eden剩余空间(15-8=7)不足以分配给obj3,因此触发第一次Minor GC来释放空间给obj3,obj1和obj2晋升到幸存区,年龄为1,各区使用情况: Eden[obj3]: 12/15, S0: 0/15, S1[obj1(age=1),obj2(age=1)]: 8/15, Old: 0/45
对象obj4创建成功之前,虚拟机检测到Eden剩余空间(15-12=3)不足以分配给obj4,因此触发第二次MinorGC来释放空间给obj4,这次GC中由于Survivor区中的obj1和obj2的大小之和8超过了Survivor大小15的一半,所以这两个对象将被提前晋升到老年代,而对象obj3由于没有任何引用,直接被回收了,之后各区使用情况: Eden[obj4]: 4/15, S0: 0/15, S1: 0/15, Old[obj1,obj2]: 8/45

至此,关于对象在堆内各区分配的几种情况就大致讲解到这里。下一章将了解一下垃圾收集器的原理。

上一篇:理解JVM(3)- 运行时数据区

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 206,214评论 6 481
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 88,307评论 2 382
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 152,543评论 0 341
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 55,221评论 1 279
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 64,224评论 5 371
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 49,007评论 1 284
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 38,313评论 3 399
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 36,956评论 0 259
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 43,441评论 1 300
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 35,925评论 2 323
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 38,018评论 1 333
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 33,685评论 4 322
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 39,234评论 3 307
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 30,240评论 0 19
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 31,464评论 1 261
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 45,467评论 2 352
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 42,762评论 2 345

推荐阅读更多精彩内容