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

139 lines
6.9 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
---
tags: [test/review, java, gc-algorithm, cms, g1, zgc, young-gen]
create time: 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 个要点即可得满分;完全正确需覆盖全部要点。
## 关联笔记
- [[01.Java/jvm/JVM 内存模型]]