278 lines
12 KiB
JSON
278 lines
12 KiB
JSON
{
|
||
"topic": "gc-deep-dive",
|
||
"type": "multiple_choice",
|
||
"schema_version": "1.0.0",
|
||
"generated": "2026-09-03T00:00:00Z",
|
||
"questions": [
|
||
{
|
||
"id": "mc-001",
|
||
"type": "multiple_choice",
|
||
"difficulty": 3,
|
||
"tags": [
|
||
"GC",
|
||
"GC Roots",
|
||
"可达性分析"
|
||
],
|
||
"question": "以下是 HotSpot JVM 进行可达性分析时使用的 GC Roots 类型的有哪些？（多选）",
|
||
"options": {
|
||
"A": "静态变量（静态字段引用的对象）",
|
||
"B": "局部变量/栈帧中引用的对象",
|
||
"C": "活跃线程（当前正在运行的线程对象）",
|
||
"D": "class 对象（类的元数据对象）",
|
||
"E": "方法参数临时值（调用时压栈的立即数完成态对象）"
|
||
},
|
||
"answer": [
|
||
"A",
|
||
"B",
|
||
"C",
|
||
"D"
|
||
],
|
||
"explanation": "GC Roots 的七种典型来源包括：①静态变量（静态字段引用的对象）；②局部变量/栈引用（栈帧局部变量表中引用的对象）；③JNI 引用（Native 方法引用的对象）；④常量池/常量引用；⑤活跃线程对象；⑥类对象（class 对象）；⑦synchronized 锁对象。因此 A、B、C、D 都对。E 是干扰项：方法参数临时变量同样属于栈帧局部变量范围，已经由 B 覆盖，并不存在单独列出的\"立即对象\"这一 Root 类型，且描述本身不严谨。",
|
||
"source": null,
|
||
"related": []
|
||
},
|
||
{
|
||
"id": "mc-002",
|
||
"type": "multiple_choice",
|
||
"difficulty": 3,
|
||
"tags": [
|
||
"GC",
|
||
"STW",
|
||
"GC代价",
|
||
"吞吐量"
|
||
],
|
||
"question": "以下哪些是垃圾回收（GC）本身带来的代价？（多选）",
|
||
"options": {
|
||
"A": "Stop-The-World（STW）暂停导致应用线程停顿",
|
||
"B": "GC 需要额外维护引用/标记信息占用内存",
|
||
"C": "垃圾回收必然提高应用的吞吐量",
|
||
"D": "产生内存碎片，可能导致大对象分配失败",
|
||
"E": "GC 停顿时间不可预测，影响延迟稳定性"
|
||
},
|
||
"answer": [
|
||
"A",
|
||
"B",
|
||
"D",
|
||
"E"
|
||
],
|
||
"explanation": "GC 的主要代价包括：STW 暂停（A）、额外内存开销用于标记信息/卡表等（B）、内存碎片增加分配失败概率（D）、停顿时间不可预测影响延迟（E），以及 CPU 消耗。C 是明确的干扰项：GC 会消耗 CPU、占用内存，通常会降低吞吐量或与业务争抢资源，绝不可能\"必然提高吞吐量\"。",
|
||
"source": null,
|
||
"related": []
|
||
},
|
||
{
|
||
"id": "mc-003",
|
||
"type": "multiple_choice",
|
||
"difficulty": 4,
|
||
"tags": [
|
||
"GC",
|
||
"CMS",
|
||
"并发标记"
|
||
],
|
||
"question": "关于 CMS 收集器致命缺陷的说法，正确的有哪些？（多选）",
|
||
"options": {
|
||
"A": "会产生\"浮动垃圾\"（Floating Garbage），需要预留空间",
|
||
"B": "使用标记-清除算法，容易产生内存碎片",
|
||
"C": "当并发清除失败时进入 Concurrent Mode Failure，退化为 Serial Old 阻塞回收",
|
||
"D": "对 CPU 资源不敏感，单核环境完全不受影响",
|
||
"E": "CMS 采用增量更新（Incremental Update）来保证标记正确性"
|
||
},
|
||
"answer": [
|
||
"A",
|
||
"B",
|
||
"C",
|
||
"E"
|
||
],
|
||
"explanation": "CMS 的四大致命问题：①浮动垃圾——并发阶段新增垃圾需要预留空间（A）；②标记-清除算法天然产生碎片（B）；③出现 Concurrent Mode Failure 时退化为 Serial Old 全量回收、STW 暂停长（C）；④CMS 对 CPU 资源敏感——并发回收占用于多个线程，单核环境下基本退化。E 也正确：CMS 的并发标记/清理正是依靠增量更新（Incremental Update）保证标记正确性。D 说法与事实相反，是干扰项。",
|
||
"source": null,
|
||
"related": []
|
||
},
|
||
{
|
||
"id": "mc-004",
|
||
"type": "multiple_choice",
|
||
"difficulty": 3,
|
||
"tags": [
|
||
"GC",
|
||
"G1",
|
||
"Region"
|
||
],
|
||
"question": "G1 收集器中，Region 可能充当以下哪些角色？（多选）",
|
||
"options": {
|
||
"A": "Eden（新生代对象分配区）",
|
||
"B": "Survivor（存活对象复制区）",
|
||
"C": "Old（老年代对象区）",
|
||
"D": "Humongous（大对象专用区）",
|
||
"E": "Perm（永久代区）"
|
||
},
|
||
"answer": [
|
||
"A",
|
||
"B",
|
||
"C",
|
||
"D"
|
||
],
|
||
"explanation": "G1 将内存划分为大小相等的 Region，每个 Region 可以动态扮演 Eden、Survivor、Old、Humongous 或 free 五种角色之一，因此 A、B、C、D 均正确。E 是干扰项：Perm（永久代）是 JRockit / HotSpot 的类元数据概念，G1 Region 中并没有 Perm 角色（JDK8 起的元空间已移出堆外）。",
|
||
"source": null,
|
||
"related": []
|
||
},
|
||
{
|
||
"id": "mc-005",
|
||
"type": "multiple_choice",
|
||
"difficulty": 5,
|
||
"tags": [
|
||
"GC",
|
||
"并发标记",
|
||
"漏标",
|
||
"SATB"
|
||
],
|
||
"question": "并发标记解决\"漏标\"（对象被错误判定为不可达）问题的典型方案有哪些？（多选）",
|
||
"options": {
|
||
"A": "增量更新（Incremental Update）",
|
||
"B": "SATB（Snapshot At The Beginning，起始快照）",
|
||
"C": "染色指针（Colored Pointer）+ 读屏障（Read Barrier）",
|
||
"D": "保守式扫描直接标记所有存活对象",
|
||
"E": "使用弱引用清理避免对象被漏标"
|
||
},
|
||
"answer": [
|
||
"A",
|
||
"B",
|
||
"C"
|
||
],
|
||
"explanation": "并发标记过程中黑色对象直接引用白色对象会造成漏标，主流方案有三：①增量更新（CMS 采用）——记录被重写的黑色对象引用（A）；②SATB（G1 采用）——在起始快照下记录被删除的引用（B）；③染色指针+读屏障（ZGC/CMS 新旧版采用）——利用指针染色标记引用状态（C）。D 是干扰项，\"保守式\"并非解决漏标的方案；E 与漏标问题无关，垃圾引用机制与标记的正确性回路没有直接对应。",
|
||
"source": null,
|
||
"related": []
|
||
},
|
||
{
|
||
"id": "mc-006",
|
||
"type": "multiple_choice",
|
||
"difficulty": 4,
|
||
"tags": [
|
||
"GC",
|
||
"老年代",
|
||
"标记-压缩",
|
||
"CMS"
|
||
],
|
||
"question": "HotSpot 在老年代（Major GC）回收时可采用的算法组合的有哪些？（多选）",
|
||
"options": {
|
||
"A": "标记-清除（Mark-Sweep）作为 CMS 的核心算法",
|
||
"B": "标记-压缩（Mark-Compact）用于整理旧对象减少碎片",
|
||
"C": "标记-复制（Copying）在老年代且回收率低时作为首选",
|
||
"D": "CMS 采用标记-清除，遇碎片过多时退回标记-压缩的 Serial Old",
|
||
"E": "三色标记法本身即可作为独立的老年代回收算法"
|
||
},
|
||
"answer": [
|
||
"A",
|
||
"B",
|
||
"D"
|
||
],
|
||
"explanation": "老年代常见的回收算法组合：CMS 使用标记-清除（A），Serial Old / 回退的收集器使用标记-压缩（B），当 CMS 碎片过多/并发失败时启动 Serial Old 进行标记-压缩整理（D），这些都正确。C 是干扰项：复制算法只用于存活率低的新生代，老年代存活率高，不会以复制算法为首选。E 错误：三色标记只是标记阶段的概念，不是独立可以完成回收的完整算法。",
|
||
"source": null,
|
||
"related": []
|
||
},
|
||
{
|
||
"id": "mc-007",
|
||
"type": "multiple_choice",
|
||
"difficulty": 4,
|
||
"tags": [
|
||
"GC",
|
||
"收集器",
|
||
"低延迟"
|
||
],
|
||
"question": "从设计目标上看，以下哪些垃圾收集器在核心设计中就明确以\"极低延迟\"（近实时、亚毫秒级停顿）为优先？（多选）",
|
||
"options": {
|
||
"A": "ZGC（Z Garbage Collector）",
|
||
"B": "Shenandoah",
|
||
"C": "Serial",
|
||
"D": "CMS（Concurrent Mark Sweep）",
|
||
"E": "G1（Garbage-First）"
|
||
},
|
||
"answer": [
|
||
"A",
|
||
"B"
|
||
],
|
||
"explanation": "ZGC（A）和 Shenandoah（B）是近年来专门为\"极低延迟\"设计的收集器：ZGC 基于染色指针 + 读屏障，转换到并发转移阶段，停顿可以控制在亚毫秒级；Shenandoah 同样通过并发转移（转移过程中读写屏障）把停顿压低到接近 ZGC 的水平。C、D、E 是干扰项：Serial 是单线程短停顿无法保证的收集器；CMS 虽然以\"低停顿\"为卖点，但它是用牺牲吞吐换取停顿下降，且存在浮动垃圾/并发失败，并非以\"极低延迟\"为核心设计目标；G1 只是提供了可配置的停顿时间目标（默认把 STW 控制在几百 ms 内），并不以亚毫秒级停顿为设计初衷。",
|
||
"source": null,
|
||
"related": []
|
||
},
|
||
{
|
||
"id": "mc-008",
|
||
"type": "multiple_choice",
|
||
"difficulty": 3,
|
||
"tags": [
|
||
"GC",
|
||
"Minor GC",
|
||
"新生代"
|
||
],
|
||
"question": "关于 Minor GC 触发条件与回收范围的描述，正确的有哪些？（多选）",
|
||
"options": {
|
||
"A": "主要在 Eden 区满时被触发",
|
||
"B": "回收范围只涉及新生代（Eden + Survivor）",
|
||
"C": "Minor GC 做完后会把存活对象晋升（Promotion）到老年代",
|
||
"D": "Minor GC 必然每次都做完整堆回收",
|
||
"E": "Minor GC 通常伴随全程 Stop-The-World，停顿短"
|
||
},
|
||
"answer": [
|
||
"A",
|
||
"B",
|
||
"C",
|
||
"E"
|
||
],
|
||
"explanation": "Minor GC（也被称为 Young GC）：A 启动——当 Eden 区满时触发；B 回收范围通常只在新生代（Eden 和 Survivor）；C 经过几次复制后仍存活的对象会通过晋升（Promotion）进入老年代；E 使用复制算法且只处理新生代，相对停顿短。D 是干扰项：Minor GC 并不会做完整堆回收，它是局部回收，与 Full GC（全堆回收）是不同概念。",
|
||
"source": null,
|
||
"related": []
|
||
},
|
||
{
|
||
"id": "mc-009",
|
||
"type": "multiple_choice",
|
||
"difficulty": 2,
|
||
"tags": [
|
||
"GC",
|
||
"GC Roots",
|
||
"JNI",
|
||
"常量池"
|
||
],
|
||
"question": "以下哪些属于 GC Roots 的典型来源？（多选）",
|
||
"options": {
|
||
"A": "静态变量（静态字段引用的对象）",
|
||
"B": "恒定常量池（常量/字面量引用的对象）",
|
||
"C": "JNI 引用（本地方法引用的对象）",
|
||
"D": "synchronized 锁对象（被锁住的对象）",
|
||
"E": "数据库连接池里空闲的对象"
|
||
},
|
||
"answer": [
|
||
"A",
|
||
"B",
|
||
"C",
|
||
"D"
|
||
],
|
||
"explanation": "GC Root 的常见源头：静态变量（A）、常量池/常量引用（B）、JNI 引用（C）、synchronized 锁对象（D），以及活跃线程、局部变量、类对象等，都正确。E 是干扰项：连接池缓存对象尽管可能存活，但若没有 A-D 等任一 Root 直接/间接引用，仍会被判定为不可达并回收——\"被缓存\"这一事实本身并不是独立的 GC Root 类型。",
|
||
"source": null,
|
||
"related": []
|
||
},
|
||
{
|
||
"id": "mc-010",
|
||
"type": "multiple_choice",
|
||
"difficulty": 5,
|
||
"tags": [
|
||
"GC",
|
||
"G1",
|
||
"Region",
|
||
"Humongous"
|
||
],
|
||
"question": "关于 G1 对大对象和 Region 的说法，哪些是正确的？（多选）",
|
||
"options": {
|
||
"A": "超过 Region 大小一半的大对象分配专有的 Humongous Region",
|
||
"B": "Humongous 对象不做局部转移，回收时需要提前整体判定",
|
||
"C": "Region 只有在被分配为 Eden 后才会变成 Old",
|
||
"D": "大对象分配可能触发 Young GC（新生代 GC）以释放空间",
|
||
"E": "大区碎片化是大对象分配失败的直接原因"
|
||
},
|
||
"answer": [
|
||
"A",
|
||
"B",
|
||
"D"
|
||
],
|
||
"explanation": "A 正确：超过 Region 大小一半的对象被标记为 Humongous，放入连续的 Humongous Region。B 正确：巨型对象不参与普通 Region 的复制/转移，需要专门整体处理（Humongous 分配/清除依赖整块判定）。D 正确：分配大对象时若没有足够连续 Region，可能会触发 Young GC 来腾出空间。C 是伪项：Region 角色并非只能 Eden→Old，Eden 和 Survivor 之间互相转换，Old Region 也可能通过分配直接转入。E 错误：碎片影响大对象分配，但并非\"分配失败\"的直接原因，概念表述混乱。",
|
||
"source": null,
|
||
"related": []
|
||
}
|
||
]
|
||
} |