Major GC和Full GC的区别是什么？触发条件呢？

R

RednaxelaFX 2016-03-31 #1

针对HotSpot VM的实现，它里面的GC其实准确分类只有两大种：

Partial GC：并不收集整个GC堆的模式

Young GC：只收集young gen的GC
Old GC：只收集old gen的GC。只有CMS的concurrent collection是这个模式
Mixed GC：收集整个young gen以及部分old gen的GC。只有G1有这个模式

Full GC：收集整个堆，包括young gen、old gen、perm gen（如果存在的话）等所有部分的模式。

Major GC通常是跟full GC是等价的，收集整个GC堆。但因为HotSpot VM发展了这么多年，外界对各种名词的解读已经完全混乱了，当有人说“major GC”的时候一定要问清楚他想要指的是上面的full GC还是old GC。

最简单的分代式GC策略，按HotSpot VM的serial GC的实现来看，触发条件是：

young GC：当young gen中的eden区分配满的时候触发。注意young GC中有部分存活对象会晋升到old gen，所以young GC后old gen的占用量通常会有所升高。
full GC：当准备要触发一次young GC时，如果发现统计数据说之前young GC的平均晋升大小比目前old gen剩余的空间大，则不会触发young GC而是转为触发full GC（因为HotSpot VM的GC里，除了CMS的concurrent collection之外，其它能收集old gen的GC都会同时收集整个GC堆，包括young gen，所以不需要事先触发一次单独的young GC）；或者，如果有perm gen的话，要在perm gen分配空间但已经没有足够空间时，也要触发一次full GC；或者System.gc()、heap dump带GC，默认也是触发full GC。

HotSpot VM里其它非并发GC的触发条件复杂一些，不过大致的原理与上面说的其实一样。

当然也总有例外。Parallel Scavenge（-XX:+UseParallelGC）框架下，默认是在要触发full GC前先执行一次young GC，并且两次GC之间能让应用程序稍微运行一小下，以期降低full GC的暂停时间（因为young GC会尽量清理了young gen的死对象，减少了full GC的工作量）。控制这个行为的VM参数是-XX:+ScavengeBeforeFullGC。这是HotSpot VM里的奇葩嗯。可跳传送门围观：

JVM full GC的奇怪现象，求解惑？ - RednaxelaFX 的回答

并发GC的触发条件就不太一样。以CMS GC为例，它主要是定时去检查old gen的使用量，当使用量超过了触发比例就会启动一次CMS GC，对old gen做并发收集。

T

Ted Mosby 2017-02-05 #2

1. Full GC定义是相对明确的，就是针对整个新生代、老生代、元空间（metaspace，java8以上版本取代perm gen）的全局范围的GC；

2. Minor GC和Major GC是俗称，在Hotspot JVM实现的Serial GC, Parallel GC, CMS, G1 GC中大致可以对应到某个Young GC和Old GC算法组合；

3. 最重要是搞明白上述Hotspot JVM实现中几种GC算法组合到底包含了什么。

3.1 Serial GC算法：Serial Young GC ＋ Serial Old GC （敲黑板！敲黑板！敲黑板！实际上它是全局范围的Full GC）；

3.2 Parallel GC算法：Parallel Young GC ＋非并行的PS MarkSweep GC / 并行的Parallel Old GC（敲黑板！敲黑板！敲黑板！这俩实际上也是全局范围的Full GC），选PS MarkSweep GC 还是 Parallel Old GC 由参数UseParallelOldGC来控制；

3.3 CMS算法：ParNew（Young）GC + CMS（Old）GC （piggyback on ParNew的结果／老生代存活下来的object只做记录，不做compaction）＋ Full GC for CMS算法（应对核心的CMS GC某些时候的不赶趟，开销很大）；

3.4 G1 GC：Young GC + mixed GC（新生代，再加上部分老生代）＋ Full GC for G1 GC算法（应对G1 GC算法某些时候的不赶趟，开销很大）；

4. 搞清楚了上面这些组合，我们再来看看各类GC算法的触发条件。

简单说，触发条件就是某GC算法对应区域满了，或是预测快满了。比如，

4.1 各种Young GC的触发原因都是eden区满了；

4.2 Serial Old GC／PS MarkSweep GC／Parallel Old GC的触发则是在要执行Young GC时候预测其promote的object的总size超过老生代剩余size；

4.3 CMS GC的initial marking的触发条件是老生代使用比率超过某值；

4.4 G1 GC的initial marking的触发条件是Heap使用比率超过某值，跟4.3 heuristics 类似；

4.5 Full GC for CMS算法和Full GC for G1 GC算法的触发原因很明显，就是4.3 和 4.4 的fancy算法不赶趟了，只能全局范围大搞一次GC了（相信我，这很慢！这很慢！这很慢！）；

5 题主说的 “Full GC会先触发一次Minor GC” －指的应该是

5.1 （说错了，我删了）

5.2 PS MarkSweep GC／Parallel Old GC（Full GC）之前会跑一次Parallel Young GC；

原因就是减轻Full GC 的负担。

哇～整个picture 是有点乱，希望我整理的还算清楚：）

v

vivo互联网技术 2025-04-24 #3

作者：vivo 互联网服务器团队- Li Gang

本文介绍了游戏业务使用MAT和GC日志等工具对 Full GC频率进行优化的过程。

一、背景

游戏业务面对用户端的某个工程，每天Full GC频率达到120次，业务高峰期每7分钟就会有一次Full GC。为了避免情况持续变差，最大程度减少对系统响应时间的负面影响，需要对该工程的Full GC频率进行优化。

该项目JDK版本为1.8，老年代使用CMS作为垃圾回收器，优化前的部分启动参数如下：

-Xms4608M -Xmx4608M -Xmn2048M -XX:MetaspaceSize=320M -XX:+UseConcMarkSweepGC -XX:CMSInitiatingOccupancyFraction=92 -XX:+UseCMSInitiatingOccupancyOnly

二、工具介绍

在本次优化过程中，我们主要使用了MAT和GC日志作为排查工具。MAT是一个功能强大的内存分析工具，而GC日志则用于记录Java虚拟机中的垃圾回收行为和内存情况。这两者结合起来，能够帮助开发人员深入分析程序的内存使用情况，并进行相应的优化。下文将详细的介绍这两种工具的使用方法，以及对应的优化案例。

2.1 MAT（Memory Analyzer Tool）

Eclipse Memory Analyzer Tool（MAT）是一个开源的Java堆转储分析工具。它旨在帮助开发人员识别和消除Java堆中的内存泄漏和优化内存使用。MAT允许用户分析Java堆转储文件，识别对象的内存占用情况，查找潜在的内存泄漏和冗余对象，以便执行一些内存优化。

使用MAT打开dump文件后，首先进入的是上图页面，此页面会显示dump包的缩略概览信息，包括堆大小，类数量，对象数量等信息。其中的Biggest Objects By Retained Size和Leak Suspects在问题明显时会比较有用，但对相对复杂的问题来说帮助不大。笔者比较常用的是下面这几个功能，下文将依次介绍：

2.1.1 Dominator Tree

（1）功能

展示对象的支配关系。对象A支配对象B代表从GC Root（也不一定是GC ROOT，也可以是unreachable的起点）达到对象B的所有路径都必须经过对象A，这也意味着对象A被垃圾回收后，对象B也会被回收。

这个功能相较于下面的Histogram更强调对象的引用关系，此外还可以通过Group By Class/Group By Package/Group By ClassLoader来进一步的聚合对象。

MAT的各种图标中会频繁的出现Shallow Heap Size和Retained Heap Size这两个名词，其含义如下：

Shallow Heap Size：这个对象自身在堆中的大小
Retained Heap Size：这个对象被垃圾回收后会释放的堆内存大小

上图中，情况1里对象A的Retained Heap Size = A的Shallow Heap Size + B的Shallow Heap Size +C的Shallow Heap Size，情况2里对象A的Retained Heap Size = A的Shallow Heap Size + B的Shallow Heap Size。

（2）使用方法

①上图为Group By Class的dominator tree。刚打开dominator tree时默认是不进行group的，此时可以排查单个大对象，排查完单个大对象后，需要将对象Group一下才能进行下一步的排查。

② 从上图可以看出，这个堆内的对象内存占用比较分散，说明导致问题的原因可能不止一个，这种情况下只能结合自身业务逐个排查内存占用排在前面的对象。

③ 对这些可疑的对象，右键类，选择List objects → with outgoing references展开对象列表，查看这类对象具体存了什么，判断这些对象的值是否可以再分类。

④ 根据对象的值，判断对象的业务含义，确定是哪段代码创建的对象。

⑤ 结合代码，思考这类对象是在新生代还是老年代，如果能确定都在新生代，那这些对象一般不会导致老年代快速增长。

⑥如果在老年代，需要确定其是怎么从新生代晋升的，内存占用是否有上限，上限是多少，一般多长时间能达到上限，再确定有没有问题。

2.1.2 Histogram

功能

histogram可以显示出各类对象的Shallow Heap Size和Retained Heap Size，Retained Heap Size默认不展示，需要点击菜单栏的Calculate Retained Size进行计算，堆较大时计算耗时较长。

这张表一般和Dominator Tree结合使用，我们能看到char[]占用了较大的内存，但由于Dominator Tree里聚合好的char[]都是顶层支配者，上层不会再有引用，有时无法直接确定这些对象曾经被谁持有过，这时可以通过Histogram查看同类对象，找到相似的并且reachable的对象来确定这类对象是谁创建的。但是这一步其实可以通过oql解决，所以这张表在排查过程中的使用率其实没有Histogram高。

2.1.3 OQL

功能

MAT提供的一种类似SQL的查询语句，可以对对象进行过滤。这篇官方文章里给了很多查询语句样例：https://wiki.eclipse.org/MemoryAnalyzer/OQL，这里就简单列一些笔者排查过程中用过的语句，不再赘述：

// 字符串模糊匹配
SELECT * FROM char[] b where toString(b) LIKE ".*traceId.*"
// 查找地址>0x700000000的对象
SELECT * FROM java.lang.Object t WHERE  toHex(t.@objectAddress) >= "0x700000000"
// 查找长度等于73并且retained heap size>1000B 的对象
SELECT * FROM java.lang.Object[] a where a.@length=73 and a.@retainedHeapSize>1000
// 查找长度等于65536并且上层有引用的对象
SELECT * FROM char[] a where a.@length=65536 and (inbounds(a).size()>0)

2.2 GC日志

GC日志是记录Java虚拟机中垃圾回收活动的日志文件。在GC日志中，可以看到包括垃圾回收的时间、类型（如新生代GC、老年代GC等）、回收周期、回收停顿时间、回收前后堆的使用情况等信息。GC日志打印的信息可以通过以下启动项控制：

三、案例介绍

在这篇文章中，我们将聚焦于一些具体的案例，涉及到大量被Dubbo的FutureAdapter引用的对象、Jackson的BufferRecycler导致的大量char[65536]以及对象晋升年龄阈值过小等问题。通过这些案例，我们将探讨这些具体问题的引起原因以及解决方案。

3.1 大量被Dubbo的FutureAdapter引用的对象

（1）分析过程

从上图中，我们可以看到dubbo FutureAdapter占用了230M左右的内存，前面的PSWMS对象虽然也占用了230M左右的内存，但这是业务使用的本地缓存相关对象，其内存占用是在预期范围内的，因此优先分析FutureAdapter。先右键List objects→with outgoing references展开对象列表。

发现其中有大量大小几乎一致的FutureAdapter，一个占用内存328KB左右，大小和内容几乎一致的对象约有550多个，总共占用内存200M左右。

FutureAdapter被用来执行Dubbo的异步调用，项目使用的dubbo版本为2.7.18。dubbo的同步调用本质上是一个异步转同步的过程，发起异步调用将CompletableFuture对象放到ThreadLocal的FutureContext里，然后立刻调用CompletableFuture.get方法阻塞获取返回值，获取到返回值后，dubbo不会主动清理FutureContext，因此该线程的ThreadLocal里会有一条FutureContext→ FutureAdapter→Result的引用，如下图：

然而，那550多个FutureAdapter均为不可达对象，意味着其不被ThreadLocal引用，在下次GC时会被回收，不过我们无法直接确定这些对象是在老年代还是新生代，有可能这些对象都在新生代，下次young gc时就会被回收，不会晋升到老年代，更不会导致老年代增长。

但由于这个列表里的数据有明确的业务含义，可以找到对应的业务接口，此接口单机峰值qps约为2，响应时间约100ms，每被调用一次，就会创建一个该对象列表，此时该机器的young gc频率约为10s一次。假设这些对象都在新生代没有晋升老年代，那么这些对象在新生代最大的存活数量约为((接口响应时间 + 两次young gc间隔) * 对象创建速度) = (0.1s + 10s) * 2 ≈ 20，而堆里有550多个，如果这些对象没有晋升到老年代的话数量上对不上，所以可以推测出这些对象在老年代里，需要等下次Full GC时才会被回收。

那么这些不可达的FutureAdapter为什么会在老年代？每次执行dubbo调用，dubbo都会用这次调用的FutureAdapter替换掉上次调用时存在FutureContext里的FutureAdapter，上次调用的FutureAdapter不再被GC Root引用，在下次GC时被回收。当一个线程相对频繁的执行dubbo调用时，FutureAdapter会被young gc回收，不会晋升到老年代。但在本例中，该dubbo调用被放到了corePoolSize=150，maxPoolSize=500的业务通用线程池中执行，该线程池会执行其他不需要调用dubbo服务的任务，并且该线程池的使用率并不高，这就意味着一个线程调用完dubbo服务后可能要过一段时间才能执行下一次dubbo调用。

由于这个原因导致FutureAdapter被放入ThreadLocal后，在新生代停留过长时间，最终晋升到老年代，这个"过长时间"对于此项目来说是6次young gc的间隔时长，这个时长的获取方法会在后续说明。

（2）解决方案

对于此业务来说，这个dubbo调用可以改为查询本地缓存，直接解决了问题。除此之外还有其他解决方案，需要结合自身业务选择合适的方案。

直接使用dubbo的异步调用，而不是在上层再创建一个线程池来进行调用。
合理设置线程池的大小，提高线程的利用率。
写一个Dubbo Filter，每次同步调用完后清理FutureContext（影响面可能较大，需自行评估风险）。

3.2. Jackson的BufferRecycler导致的大量char[65536]

（1）分析过程

从dominator tree中我们能看到char[]也占用了相当大的一部分内存，展开char[]，发现其中包含大量的char[65536]，使用oql统计得知不被gc root引用的有1600个，占用内存200M左右，被gc root引用的有500个，这种char[65536]里存储的数据均为http接口返回值反序列化后的字符。其被gc root引用时的链路如下，均被ThreadLocal里的BufferRecycler引用：

在Jackson库中，BufferRecycler的主要作用是管理缓冲区的重用，可以减少频繁的内存分配和释放，从而降低垃圾回收的负担，提高性能。但从堆上看，这些char数组里不可达的数量远大于可达的数量（1600:500），说明其复用率并不高，与其设计的目标不符，需要查看源码才能搞清原因。

项目使用jackson的ObjectMapper.

writeValueAsString()方法对http接口返回值进行了反序列化，使用的Jackson版本为2.10，该方法完整的执行流程如下图：

简单来说，jackson在反序列化时，会将反序列化的结果存储在多段char[]里，每当最后一个char[]空间不够存放结果时，就新建一个char[]，大小为最后使用的char[]的1.5倍，但不超过65536，反序列化结束后将char[]列表拼接起来就得到了结果，然后线程会将最后使用的那个char[]存放到ThreadLocal。此线程下次反序列化时，会从ThreadLocal取出这个char[]进行复用。这样的一个复用逻辑会有一个问题，参考下图：

图中，_segements是当前反序列化使用过的char[]列表，currentSegement是当前正在使用的char[]。一个char[]的大小最大为65536。在第二次反序列化大对象时至少会创建一个新的大小为65536的char[]（上一次的char[]是65536，再创建一个新char[]其大小仍不能超过65536）。可以看到在第一次反序列化结束后和第二次反序列化结束后，虽然ThreadLocal里存放的char[]大小都是65536，但其实它们已经不是同一个对象了。这样的一个替换是没有必要的，完全可以一直复用同一个char[]。

当业务所有http接口的返回值都大且流量也大时，每次保存在ThreadLocal里的char[65536]虽然会在下次反序列化结束时被替换导致其失去引用，但由于其在新生代只存活了一次接口请求的时间，所以不会晋升到老年代，可以被young gc回收。但是我们项目用来处理http请求的线程池都是同一个，这些接口的返回值只有一部分超过了65536，在小于的时候ThreadLocal里的char[]不会被替换，当这个char[]在ThreadLocal里停留一段时间后，就会晋升到老年代，从而导致老年代内存增长。

（2）解决方案

关闭Jackson的USE_THREAD_LOCAL_
FOR_BUFFER_RECYCLING，关闭该开关会在每次反序列化时创建一个BufferRecycler，而不是复用ThreadLocal里的BufferRecycler，这样可能导致young gc频率提高。
升级Jackson版本，请参考此issue，2.17版本的jackson在调用releaseByteBuffer时会避免较小或者相同大小的char数组替换原有数组。

由于项目使用的jackson版本是2.10，直接升级到2.17的版本跨度较大，可能带来不必要的风险，因此采用了方案1，上线后，young gc频率没有明显增加。方案2的issue里有提到使用2.16版本引入的RecyclerPool代替基于ThreadLocal的实现，这也是解决方案之一。

3.3 对象晋升年龄阈值过小

（1）背景知识

java对象从新生代晋升到老年代有多种原因，在本项目中，对象的主要晋升原因是在新生代长期存活，这个长期具体是多久有以下两个判断条件：

对象晋升年龄阈值：
可通过-XX:MaxTenuringThreshold启动项进行配置，对于CMS，默认值是6。此参数定义了对象在年轻代存活的最大年龄，如果一个对象在年轻代经过N次GC后依然存活，它将会被晋升到老年代。

动态年龄判定：
在survivor区中小于或等于某年龄的的所有对象大小的总和大于survivor空间的一定比例时，大于或等于该年龄的对象就直接进入老年代，这个比例可以通过-XX:TargetSurvivorRatio启动项控制，默认值为50，代表50%。

一个对象的年龄满足上述两个条件之一时，就会晋升到老年代，具体的晋升年龄可以通过在启动项里添加-XX:+PrintTenuringDistribution获取，添加该参数后的gc日志如下图：

其中区域2的(max 6)代表-XX:MaxTenuringThreshold启动项配置的值，也就是说对象到达这个年龄一定会晋升，而new threshold 6代表对象实际晋升的年龄，上图代表这次young gc因对象到达年龄阈值会导致9946864 bytes的对象晋升。

区域1代表动态年龄判定所需的空间大小，也就是(survivor空间大小 x targetSurvivotRatio)。此项目堆的单个survivor空间为200M，所以只要在survivor区中小于或等于某年龄的所有对象大小的总和大于200Mx50%，大于或等于该年龄的对象就会晋升，。

而下图的对象是因为动态年龄判定才晋升的，这次young gc因动态年龄判定会导致38660424 bytes的对象晋升：

（2）分析过程

优化前+调参前：

在进行dubbo和jackson以及其他业务代码上的优化前，我们保存了当时的gc日志，可以看到大部分对象都是因为年龄到达6晋升的，每次young gc约有10M~16M左右的对象晋升，显然对象的晋升年龄阈值太小，需要调大。

优化后+调参前：

在调整 JVM 参数之前，我们决定先着手进行业务上的优化。因为直接进行参数调整可能会治标不治本，无法消除潜在的隐患。在完成业务代码上的优化后，可以看到此时由于年龄达到6这一阈值晋升的对象大小从最开始的10M~16M降为了4M以下，意味着在新生代长期存活的对象数量明显减少了，但仍然有优化空间。

（3）解决方案

在完成业务代码上的优化后，我们对 JVM 参数进行了调整。将-XX:MaxTenuringThreshold参数改为15，-XX:TargetSurvivorRatio改为75%（实际上，通过调参后的gc日志我们能确定对于这个项目来说，50%也已经够用，因为年龄1到15的对象占用的总内存只有38M左右，远远小于单个survivor空间的50%），以延长对象在新生代的存活时间。我们可以观察到，尽管会有一些对象存活到年龄15的阈值才晋升，但是这部分对象的总大小变小了，大部分情况下都是小于2M。这部分对象通过添加监控的方式判断大概率是被移除（大小不足被淘汰，过期等原因）的caffeine本地缓存。