Java虚拟机：内存分配与回收策略

2401_84046876

于 2024-04-15 17:50:02 发布

阅读量869

点赞数 22

分类专栏：程序员文章标签： java jvm 开发语言

本文链接：https://blog.csdn.net/2401_84046876/article/details/137789656

版权

程序员专栏收录该内容

466 篇文章 1 订阅

订阅专栏

GC环境：垃圾收集器为Parallel Scavenge + Parallel Old，年轻代大小为100M，Eden：Survivor = 8 ：1，所以Eden为80M，两个Survivor各10M，老年代为100M。

GC分析：当要分配allocation5时，Eden空间不足，进行Minor GC，此时年轻代空间从76595K降低到888k。这是由于allocation1、allocation2、allocation3、allocation4对象的大小皆超过Survivor空间大小（10M），因此allocation1、allocation2、allocation3、allocation4对象皆通过分配担保机制提前转移到老年代，年轻代剩余的888k为JVM的内部对象，进行Minor GC后进入了Survivor区。后面的Full GC会在后面的空间分配担保进行讲解。

例子3：

Parallel Scavenge + Parallel Old

GC环境：垃圾收集器为Parallel Scavenge + Parallel Old，年轻代大小为100M，Eden：Survivor = 8 ：1，所以Eden为80M，两个Survivor各10M，老年代为100M。

GC分析：该例子跟例子2的区别是把例子2的最后两次分配10M和30M合并成了1次分配40M，结果没有进行GC，原因是在Parallel Scavenge收集器下：将要分配的对象大小 >= Eden总空间的一半，对象通过分配担保机制直接进入老年代，否则尝试进行MinorGC。

2.大对象直接进入老年代

================

所谓的大对象是指，需要大量连续内存空间的Java对象，最典型的大对象就是那种很长的字符串以及数组（例子中的byte[]数组就是典型的大对象）。

虚拟机提供了一个-XX：PretenureSizeThreshold参数，令大于这个设置值的对象直接在老年代分配。只对Serial和ParNew两款收集器有效，Parallel Scavenge收集器不认识这个参数，Parallel Scavenge收集器一般并不需要设置。

例子1：没设置PretenureSizeThreshold

GC分析：可以看出老年代为空，allocation对象正常进入新生代。

例子2：设置PretenureSizeThreshold=3145728

GC分析：可以看出老年代被占用了4M，allocation对象由于超过PretenureSizeThreshold设置的3M（3145728 = 3 * 1024 * 1024），被认为是大对象直接进入老年代。

3.长期存活的对象将进入老年代

===================

如果对象在Eden出生并经过第一次Minor GC后仍然存活，并且能被Survivor容纳的话，将被移动到Survivor空间中，并且对象年龄设为1。对象在Survivor区中每“熬过”一次Minor GC，年龄就增加1岁，当它的年龄增加到一定程度（默认为15岁），就将会被晋升到老年代中。对象晋升老年代的年龄阈值，可以通过参数-XX：MaxTenuringThreshold设置。

例子1：不设置MaxTenuringThreshol参数

GC环境：垃圾收集器为Serial + Serial Old（ParNew + Serial Old），年轻代大小为100M，Eden：Survivor = 8 ：1，所以Eden为80M，两个Survivor各10M，老年代为100M。

GC分析：没设置MaxTenuringThreshold时，MaxTenuringThreshold的默认值为15，必须经过15次Minor GC才能晋升到老年代，因此经过该例子经过两次Minor GC后，年轻代仍有3257k，即allocation1对象的仍在Survivor区。

例子2：设置参数MaxTenuringThreshold=1

GC分析：该例子跟上面差别只有一个，将MaxTenuringThreshold设为1，可以看出第二次Minor GC时，年轻代已经被清空，allocation1对象因为年龄符合MaxTenuringThreshold设置的值，因此进入老年代。

4.动态对象年龄判断

==============

如果在Survivor空间中相同年龄所有对象大小的总和大于Survivor空间的一半，年龄大于或等于该年龄的对象就可以直接进入老年代，无须等到MaxTenuringThreshold中要求的年龄。

例子1：allocation1+allocation2大于Survivor空间一半

GC环境：垃圾收集器为Serial + Serial Old（ParNew + Serial Old），年轻代大小为100M，Eden：Survivor = 8 ：1，所以Eden为80M，两个Survivor各10M，老年代为100M。

GC分析：allocation3分配时，Eden空间不足，因此触发第一次Minor GC，allocation1和allocation2对象进入Survivor区，allocation3由于太大，直接进入老年代。当第二次分配allocation4时，Eden空间不足（allocation4虽然已经=null，但是由于还未进行垃圾收集，因此空间仍未释放），触发第二次Minor GC，可以看到此时年轻代GC后为空，可以得出Survivor里面的allocation1和allocation2已经进入老年代，原因是Survivor空间中相同年龄所有对象大小的总和大于Survivor空间的一半。

例子2：allocation1+allocation2小于Survivor空间一半

GC分析：该例子跟上面的例子只差在allocation1大小从10M/4变成了10M/8，从而导致allocation1+allocation2的对象大小没有大于Survivor空间的一半，因此第二次Minor GC后，年轻代大小依然为4537k，allocation1和allocation2仍然在Survivor区。

5.空间分配担保

============

JDK 6 Update 24之后：在发生Minor GC之前，虚拟机会先检查老年代的连续空间大小是否大于新生代对象总大小或者历次晋升的平均大小, 如果是则进行Minor GC, 否则将进行Full GC。

Parallel Scavenge收集器与其他收集器在空间分配担保上有一点差别, 正常是在Minor GC前进行检查, 而Parallel Scavenge收集器在Minor GC后也会进行检查。

另外当出现大量对象在Minor GC后仍然存活的情况（最极端的情况就是内存回收后新生代中所有对象都存活），就需要老年代进行分配担保，把Survivor无法容纳的对象直接进入老年代。

例子1：

Serial + Serial Old（UseSerialGC）或者 ParNew + Serial Old（UseParNewGC）

GC环境：垃圾收集器为Serial + Serial Old（ParNew + Serial Old），年轻代大小为100M，Eden：Survivor = 8 ：1，所以Eden为80M，两个Survivor各10M，老年代为100M。

GC分析：allocation1、allocation2、allocation3占用了Eden的60M空间，allocation4分配内存时，Eden的空间已经不足，因此触发第一次Minor GC，Minor GC结束后，allocation1、allocation2、allocation3进入老年代，此时老年代剩余空间为40M，GC后剩余的698k为JVM内部对象进入其中一个Survivor。allocation7分配内存时，此时年轻代已经放了allocation4、allocation5、allocation6，已经无法放下allocation7，因此将触发Minor GC，但在触发前会进行检查，此时老年代剩余空间为不足40M，新生代的对象总大小为60M，历次晋升的平均大小为60M，因此改为进行一次Full GC，Full GC后，年轻代对象被全部晋升，老年代因为allocation1、allocation2、allocation3被赋空，内存得到回收，晋升上来allocation4、allocation5、allocation6，因此内存大小还是60M左右，但是后面的堆总量可以看到由120M降低到了60M。

自我介绍一下，小编13年上海交大毕业，曾经在小公司待过，也去过华为、OPPO等大厂，18年进入阿里一直到现在。

深知大多数Java工程师，想要提升技能，往往是自己摸索成长或者是报班学习，但对于培训机构动则几千的学费，着实压力不小。自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！

因此收集整理了一份《2024年Java开发全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友，同时减轻大家的负担。