Files
autumn-recruitment/01.Java/jvm/垃圾回收算法与收集器_test.md
T

6.9 KiB
Raw Blame History

tags, create time
tags create time
test/review
java
gc-algorithm
cms
g1
zgc
young-gen
2026-08-09 12:00

垃圾回收算法与收集器_测试题

概述

本测试覆盖标记-清除/复制/整理三种经典 GC 算法、分代理论依据,以及 CMS、G1、ZGC 三大收集器的设计原理和选型策略,共 10 道题目(6 道选择题 + 3 道填空题 + 1 道简答题)。


一、选择题(6道,由浅入深)

难度阶梯: Q1-Q2 基础概念 → Q3-Q4 核心原理 → Q5-Q6 深入应用/边界场景

Q1(基础)— 考察定义层面

新生代 Eden:S0:S1 的经典比例设计中,Eden 区占新生代的份额大约是:

A. 1/2(50%)
B. 1/3(约 33%)
C. 4/5(80%)
D. 9/10(90%)

Q2(基础)— 考察概念记忆

以下哪种 GC 算法的主要缺点是会产生大量内存碎片?

A. 标记-复制(Mark-Copy)
B. 标记-整理(Mark-Compact)
C. 标记-清除(Mark-Sweep)
D. G1 的 Mixed GC

Q3(进阶)— 考察核心原理

CMS 收集器有四个阶段,其中不会暂停用户线程的阶段是:

A. 初始标记(Initial Mark)
B. 并发标记(Concurrent Mark)
C. 预标记(Re-Mark)
D. 以上三个阶段都会 STW

Q4(进阶)— 考察比较与辨析

G1 收集器与传统的 CMS 收集器相比,最核心的架构区别在于:

A. G1 不再物理分隔新生代和老年代,而是将堆划分为多个大小相等的 Region
B. G1 只使用标记-清除算法,而 CMS 使用标记-复制算法
C. G1 的所有 GC 动作都在单线程内串行完成
D. G1 不支持并发回收,必须依赖 Full GC

Q5(深入)— 考察场景推理

某服务堆大小约为 16GB,要求 GC 暂停时间控制在 200ms 以内,对吞吐量有一定要求但不追求极致低延迟。根据收集器选型决策树,最合适的选择是:

A. CMS
B. G1
C. ZGC
D. Parallel Old

Q6(深入)— 考察边界场景

ZGC 能够实现暂停时间不超过 10ms(无论堆大小)的核心技术是:

A. 在写屏障中记录所有引用修改,然后批量重定位
B. 染色指针 + 加载屏障,将原本沉重的写屏障移到加载时机
C. 利用多核并行地在一个 STW 窗口内完成全量回收
D. 将所有对象分配到连续内存区域,避免引用失效


二、填空题(3道)

F1 — 填空1

CMS 收集器有三个显著缺陷:浮动垃圾(并发清扫阶段产生的新对象只能等下一次 GC 处理)、(1)(基于标记-清除算法容易产生碎片)、以及 CPU 资源敏感(并发阶段和用户代码共享 CPU)。CMS 在 JDK (2) 中被彻底移除。

提示: 回顾 CMS 缺陷部分的具体描述和生命周期。

F2 — 填空2

G1 收集器中有一个特殊的概念叫 ROI(Return of Investment),用于排序 Region 的回收优先级——优先回收__(1)最大的 Region。此外,超过半个 Region 大小的超大对象会直接分配到(2)__ Region,以避免碎片问题。

提示: ROI = 回收得到的空间 / 花费的时间,超大对象的特殊命名与其用途相关。

F3 — 填空3

根据选型决策树:堆 < 4GB 推荐 Parallel GC(吞吐优先)或 CMS(JDK 8 低延迟需求);4GB ≤ 堆 ≤ 32GB 推荐 (1);堆 > 32GB 且要求暂停 < 10ms 推荐 (2)。

提示: 这是生产环境中最常用的两个收集器选择分界线。


三、简答题(1道)

S1

某电商大促活动即将开始,负责团队正在做线上 GC 压测。现有三个待选收集器:CMS、G1、ZGC。已知以下条件:

  • 堆大小约 24GB
  • 要求 GC 暂停时间尽量短(P99 < 300ms)
  • 业务允许一定的吞吐量损失
  • 当前运行在 JDK 11 之上

请回答:

  1. 你会推荐哪个(些)收集器?给出决策理由。
  2. ZGC 相比 G1 的核心优势是什么?它的两项关键技术名词是什么?
  3. 如果在压测中发现使用 CMS 时频繁出现 Full GC,可能的原因是什么?(至少给出两条)

答题框架提示:

  • 第 1 问先看堆大小落在选型树的哪个区间
  • 第 2 问直接提取 ZGC 的技术细节
  • 第 3 问从 CMS 的三个缺陷出发推导

参考答案与解析

选择题答案

题号 正确答案 解析
Q1 C HotSpot 通过 Eden:S0:S1 = 8:1:1 的比例设计,Eden 占 8/10 = 80%,让绝大多数新对象直接分配到 Eden。只有少量长寿对象才进入 Survivor。
Q2 C 标记-清除算法不移动对象、不复制,只是在清除未标记区域时留下空洞,产生碎片。标记-复制和标记-整理都能避免碎片。
Q3 B CMS 的初始标记和预标记都需要短暂 STW,并发标记和并发清扫是完全与用户线程并行的。所以选 B。
Q4 A G1 的最大创新是将堆划分为最多 2048 个 Region(每个 1~32MB),不再物理分隔新生代和老年代。B 错误(G1 不使用纯标记-清除),C 错误(G1 并行并发),D 错误(G1 支持并发)。
Q5 B 堆大小 24GB 落在 4GB~32GB 区间,选型决策树明确指出这个范围推荐 G1。ZGC 虽然也适用但成本更高(吞吐量略低),Parallel Old 吞吐优先不适合低延迟场景。
Q6 B ZGC 的核心创新是染色指针(在指针高位 bit 编码颜色信息)和加载屏障(读引用时才执行重定位),将写屏障移到加载时机。A 描述的是传统写屏障方式。

填空题答案

题号 答案 解析
F1 (1)内存碎片 (2)JDK 14 CMS 基于标记-清除算法,必然产生碎片,可能导致大对象无法分配而提前触发 Full GC。CMS 在 JDK 9 标记废弃,JDK 14 彻底移除。
F2 (1)ROI(回收价值) (2)Humongous G1 按 ROI 排序优先回收性价比最高的 Region。超大对象(超过半 Region)直接放入 Humongous Region 避免跨区碎片。
F3 (1)G1 (2)ZGC 4GB~32GB 是 G1 的主战场(大多数生产环境的默认选择),>32GB 且要求低延迟时切换 ZGC。

简答题参考答案

S1:参考答案要点:

  1. 堆大小 24GB 落在 4GB~32GB 区间,推荐 G1 作为首选。如果预算允许且对延迟要求更严苛,也可以评估 ZGC。JDK 11 以上已支持 ZGC 生产使用。
  2. ZGC 的核心优势是暂停时间绝对不超过 10ms,与堆大小无关。两项关键技术:染色指针(Colored Pointers)和加载屏障(Load Barrier)。
  3. CMS 频繁 Full GC 的可能原因:① 内存碎片过多导致大对象无法在 Eden 分配直接进入老年代,老年代很快满;② CMS 并发清扫阶段产生的"浮动垃圾"积累到下一次的 Full GC;③ 老年代阈值配置不合理,GC 未能及时触发。

评分标准:答出任意 2 个要点即可得满分;完全正确需覆盖全部要点。

关联笔记