#yyds干货盘点# 彻底理解对象内存分配及Minor GC和Full GC全过程

Posted 2022-01-18 公众号JavaEdge

线上的老年代频繁Full GC的案例，理解：

• 整个对象分配以及转移到老年代
• Minor GC和Full GC过程

案例

某数据计算系统，日处理数据量在上亿的规模。系统会不断从mysql及其他数据源提取大量数据，加载到自己的JVM内存进行计算处理：

这数据计算系统不停通过SQL语句和其他方式从各种数据存储中提取数据到内存中来进行计算，大致当时的生产负载是每分钟大概需要执行500次数据提取和计算的任务。 但这是一套分布式运行的系统，所以生产环境部署了多台机器，每台机器大概每分钟负责执行100次数据提取和计算的任务。 每次会提取大概1万条左右的数据到内存里来计算，平均每次计算大概需要耗费10s。 然后每台机器是4核8G的配置，JVM内存给了4G，其中新生代和老年代分别是1.5G的内存空间： 

该系统到底多块会塞满新生代？

既然这个系统每台机器上部署的实例，每分钟会执行100次数据计算任务，每次是1万条数据需要计算10秒的时间，那每次1万条数据大概会占多大内存？ 这里每条数据都较大，大概每条数据包含平均20个字段，可认为平均每条数据在1KB左右。那每次计算任务的1万条数据就对应了10MB的大小。 若新生代按8:1:1分配Eden和两块Survivor区域，那Eden=1.2GB，每块Survivor=100MB：

按此内存，每次执行一个计算任务，就会在Eden分配10MB左右对象，那一分钟大概对应100次计算任务。基本上一分钟过后，Eden区里就满了。所以新生代里的Eden区，基本上1min左右就满了。

触发Minor GC时，会有多少对象进入老年代？

假设新生代Eden在1min后满了，然后接着继续执行计算任务时，必然导致需要进行Minor GC，回收一部分垃圾对象。执行Minor GC之前会先进行检查： 第一步，老年代可用内存＞新生代全部对象？ 此时老年代空，有1.5G可用内存，新生代Eden大概算做有1.2G对象。

此时，即使一次Minor GC，全部对象都存活，老年代也能放下，则此时就会直接执行Minor GC。

那此时Eden有多少对象存活，无法被GC呢？

每个计算任务1万条数据，需计算10s，假设此时80个计算任务都执行结束，但还有20个计算任务共计200MB数据还在计算，此时就是200MB对象是存活的，不能被GC，然后有1G对象可GC：

此时一次Minor GC就会回收1G对象，然后200M对象能放入Survivor区吗？

不能！因为任一块Survivor区实际上就100M空间，此时就会通过空间担保机制，让这200MB对象直接进入老年代，占用里面200MB内存空间，然后Eden区清空：

系统运行多久，老年代大概就会填满？

这系统大概运行多久，老年代会填满？按上述计算，每min都是个轮回，大概就是每min都会把新生代Eden填满，然后触发一次Minor GC，然后大概都会有200MB数据进入老年代。 若2min过去了，此时老年代有400M被占用，只有1.1G可用，若第3分钟运行完毕，又要进行Minor GC，会做什么检查呢？

1. 先检查老年代可用空间 ＞ 新生代全部对象？

此时老年代可用空间1.1GB，新生代对象有1.2GB，此时假设一次Minor GC过后新生代对象全部存活，老年代是放不下的，就得看“-XX:-HandlePromotionFailure”参数，一般都会打开 此时会进入第二步检查

2. 老年代可用空间 ＞ 历次Minor GC过后进入老年代的对象的平均大小

大概每min执行一次Minor GC，每次大概200M对象进入老年代。那此时发现老年代1.1G，大于每次Minor GC后平均的200M。所以本次Minor GC后大概率还是有200MB对象进入老年代，1.1G可用空间足够。所以此时就会放心执行一次Minor GC，然后又是200MB对象进入老年代。 转折点大概在运行了7min后，7次Minor GC后，大概1.4G对象进入老年代，老年代剩余空间就不到100MB ，几乎快满：

系统运行多久，老年代会触发1次Full GC？

大概在第8min运行结束时，新生代又满，执行Minor GC前进行检查，发现老年代只有100M，比200M小，就会直接触发一次Full GC。 Full GC会把老年代的垃圾对象都给回收，假设此时老年代被占据的1.4G全都是可回收对象，则此时一次就会把这些对象都回收：

然后接着就会执行Minor GC，此时Eden区情况，200MB对象再次进入老年代，之前Full GC就是为这些新生代本次Minor GC要进入老年代的对象准备：

基本平均7、8分钟一次Full GC，这频率相当高。因为每次Full GC很慢， 性能很差。

如何JVM调优？

因为这数据计算系统，每次Minor GC的时候，必然会有一批数据没计算完，但按现有内存模型，最大问题是每次Survivor区放不下存活对象。 所以增加新生代内存比例，3GB堆内存，2GB分给新生代， 1GB给老年代。这样Survivor区大概200M，每次刚好能放下Minor GC后存活对象：

只要每次Minor GC过后200MB存活对象可以放Survivor区域，等下次Minor GC时，这个Survivor区的对象对应的计算任务早就结束了，都可以回收。此时比如Eden区1.6G被占满，然后Survivor1有200MB上一轮 Minor GC后存活的对象：

然后此时执行Minor GC，就会把Eden 1.6G对象回收，Survivor1里200MB对象也会回收，然后Eden区剩余200MB存活对象会放入Survivor2区：

以此类推，基本上就很少对象会进入老年代，老年代里的对象也不会太多。 通过这个优化，成功将生产系统的老年代Full GC频率从几min一次降低到几h一次，大幅提升系统性能，避免频繁Full GC对系统性能影响。 一个动态年龄判定升入老年代的规则，若： $Survivor区中的同龄对象＞超过Survivor区内存/2$ 就要直接升入老年代。所以此处优化仅是为说明：增加Survivor区大小，让Minor GC后的对象进入Survivor区中，避免进入老年代。 为避免动态年龄判定规则把Survivor区中的对象直接升入老年代，若新生代内存有限，可调整undefined- XX:SurvivorRatio=8undefined参数：默认Eden区比例80%，也可降低Eden区比例，给两块Survivor区更多内存空间，然后让每次Minor GC后的对象进入Survivor区中，还可避免动态年龄判定规则直接把他们送入老年代。

垃圾回收器

在新生代和老年代进行垃圾回收的时候，都是要用垃圾回收器进行回收的，不同的区域用不同的垃圾回收器。

Serial和Serial Old垃圾回收器：分别用来回收新生代和老年代的垃圾对象 工作原理就是单线程运行，垃圾回收的时候会停止我们自己写的系统的其他工作线程，让我们系统直接卡死不动，然后让他们垃圾回收，这个现在一般写后台Java系统几乎不用。

ParNew和CMS垃圾回收器：ParNew现在一般都是用在新生代的垃圾回收器，CMS是用在老年代的垃圾回收器，他们都是多线程并发的机制，性能更好，现在一般是线上生产系统的标配组合。下周会着重分析这两个垃圾回收器。

G1垃圾回收器：统一收集新生代 和老年代，采用了更加优秀的算法和设计机制，是下下周的重点，一周都会来分析G1垃圾回收器的工作原理和优缺点。