.NET 诊断与性能试题 05：dotnet-gcdump 与内存泄漏排查
081 关于GC dump，哪一项准确描述了应依赖的平台契约？
难度： 基础
- A. gcdump 可以完整解释任意本机内存增长
- B. 它不是完整进程转储，不包含所有线程栈和本机内存细节
- C. 只要观察到“进程 RSS 增长但托管堆稳定”，就能把这次现象视为所有环境中的固定行为。
- D. dotnet-gcdump 采集托管堆对象和引用关系的快照，适合分析类型占用与保活路径
查看答案与解析
正确答案D
正确项给出了GC dump可直接依赖的规则：“dotnet-gcdump 采集托管堆对象和引用关系的快照，适合分析类型占用与保活路径”。“它不是完整进程转储，不包含所有线程栈和本机内存细节”是应用规则前必须确认的边界，不是规则本身；“gcdump 可以完整解释任意本机内存增长”则把常见现象或实现细节扩大成了平台保证。场景“进程 RSS 增长但托管堆稳定”只能作为排查线索，仍需结合目标框架、发布方式和运行时证据验证。
082 生产环境出现“进程 RSS 增长但托管堆稳定”时，针对GC dump应如何排查？
难度： 进阶
- A. 直接采用“gcdump 可以完整解释任意本机内存增长”解释现象，不再收集目标进程和发布配置证据。
- B. 只增加机器资源或重启进程，以一次恢复结果代替对“它不是完整进程转储，不包含所有线程栈和本机内存细节”的验证。
- C. 先验证“它不是完整进程转储，不包含所有线程栈和本机内存细节”，再使用运行时指标、日志或最小复现检查“dotnet-gcdump 采集托管堆对象和引用关系的快照，适合分析类型占用与保活路径”是否成立。
- D. 只检查代码是否能够编译，通过后便认定“dotnet-gcdump 采集托管堆对象和引用关系的快照，适合分析类型占用与保活路径”在当前部署中必然成立。
查看答案与解析
正确答案C
“进程 RSS 增长但托管堆稳定”可能由多条路径造成，不能直接证明根因。合理顺序是先确认边界“它不是完整进程转储，不包含所有线程栈和本机内存细节”，再以“dotnet-gcdump 采集托管堆对象和引用关系的快照，适合分析类型占用与保活路径”组织证据。采用误区“gcdump 可以完整解释任意本机内存增长”、盲目扩容或只看编译结果，都跳过了运行配置与真实调用路径，无法形成可复核的诊断结论。
083 评审GC dump相关实现时，以下哪项判断不成立？
难度： 实战
- A. gcdump 可以完整解释任意本机内存增长
- B. dotnet-gcdump 采集托管堆对象和引用关系的快照，适合分析类型占用与保活路径
- C. 它不是完整进程转储，不包含所有线程栈和本机内存细节
- D. 遇到“进程 RSS 增长但托管堆稳定”时，应把可观察证据与平台契约分开记录，再验证二者是否一致。
查看答案与解析
正确答案A
题目要求找出不成立的判断，“gcdump 可以完整解释任意本机内存增长”正是GC dump的典型误区。主规则“dotnet-gcdump 采集托管堆对象和引用关系的快照，适合分析类型占用与保活路径”描述了实现应依赖的契约，边界“它不是完整进程转储，不包含所有线程栈和本机内存细节”限制了结论的适用范围。生产场景还需要保留指标、日志、跟踪或转储等证据，不能因为一次成功或失败就反转稳定契约。
084 准备上线涉及GC dump的改动时，哪项验收方案最完整？
难度： 实战
- A. 依据“gcdump 可以完整解释任意本机内存增长”完成修改，只要本地运行一次成功就立即发布。
- B. 依据“dotnet-gcdump 采集托管堆对象和引用关系的快照，适合分析类型占用与保活路径”实现，在“它不是完整进程转储，不包含所有线程栈和本机内存细节”成立的环境中验证，并为“进程 RSS 增长但托管堆稳定”保留可观测证据和回退条件。
- C. 按照“dotnet-gcdump 采集托管堆对象和引用关系的快照，适合分析类型占用与保活路径”修改代码，但不核对“它不是完整进程转储，不包含所有线程栈和本机内存细节”或目标发布模式。
- D. 只验证“它不是完整进程转储，不包含所有线程栈和本机内存细节”，实现仍继续依赖“gcdump 可以完整解释任意本机内存增长”这一未经证明的假设。
查看答案与解析
正确答案B
完整验收必须同时覆盖规则、边界和生产证据：实现遵守“dotnet-gcdump 采集托管堆对象和引用关系的快照，适合分析类型占用与保活路径”，部署环境满足“它不是完整进程转储，不包含所有线程栈和本机内存细节”，并能在“进程 RSS 增长但托管堆稳定”出现时定位和回退。其余方案分别依赖错误假设、遗漏环境验证或只检查边界却保留错误实现，均不能证明改动在生产环境中安全。
085 关于快照对比，哪一项准确描述了应依赖的平台契约？
难度： 基础
- A. 在相似负载阶段比较多次快照比只看单次对象数量更能发现持续增长类型
- B. 两个快照大小不同就证明存在内存泄漏
- C. 采集之间必须记录流量、缓存预热和业务状态，否则差异可能合理
- D. 只要观察到“缓存预热后对象数量上升”，就能把这次现象视为所有环境中的固定行为。
查看答案与解析
正确答案A
正确项给出了快照对比可直接依赖的规则：“在相似负载阶段比较多次快照比只看单次对象数量更能发现持续增长类型”。“采集之间必须记录流量、缓存预热和业务状态，否则差异可能合理”是应用规则前必须确认的边界，不是规则本身；“两个快照大小不同就证明存在内存泄漏”则把常见现象或实现细节扩大成了平台保证。场景“缓存预热后对象数量上升”只能作为排查线索，仍需结合目标框架、发布方式和运行时证据验证。
086 生产环境出现“缓存预热后对象数量上升”时，针对快照对比应如何排查？
难度： 进阶
- A. 直接采用“两个快照大小不同就证明存在内存泄漏”解释现象，不再收集目标进程和发布配置证据。
- B. 只增加机器资源或重启进程，以一次恢复结果代替对“采集之间必须记录流量、缓存预热和业务状态，否则差异可能合理”的验证。
- C. 只检查代码是否能够编译，通过后便认定“在相似负载阶段比较多次快照比只看单次对象数量更能发现持续增长类型”在当前部署中必然成立。
- D. 先验证“采集之间必须记录流量、缓存预热和业务状态，否则差异可能合理”，再使用运行时指标、日志或最小复现检查“在相似负载阶段比较多次快照比只看单次对象数量更能发现持续增长类型”是否成立。
查看答案与解析
正确答案D
“缓存预热后对象数量上升”可能由多条路径造成，不能直接证明根因。合理顺序是先确认边界“采集之间必须记录流量、缓存预热和业务状态，否则差异可能合理”，再以“在相似负载阶段比较多次快照比只看单次对象数量更能发现持续增长类型”组织证据。采用误区“两个快照大小不同就证明存在内存泄漏”、盲目扩容或只看编译结果，都跳过了运行配置与真实调用路径，无法形成可复核的诊断结论。
087 评审快照对比相关实现时，以下哪项判断不成立？
难度： 实战
- A. 在相似负载阶段比较多次快照比只看单次对象数量更能发现持续增长类型
- B. 采集之间必须记录流量、缓存预热和业务状态，否则差异可能合理
- C. 两个快照大小不同就证明存在内存泄漏
- D. 遇到“缓存预热后对象数量上升”时，应把可观察证据与平台契约分开记录，再验证二者是否一致。
查看答案与解析
正确答案C
题目要求找出不成立的判断，“两个快照大小不同就证明存在内存泄漏”正是快照对比的典型误区。主规则“在相似负载阶段比较多次快照比只看单次对象数量更能发现持续增长类型”描述了实现应依赖的契约，边界“采集之间必须记录流量、缓存预热和业务状态，否则差异可能合理”限制了结论的适用范围。生产场景还需要保留指标、日志、跟踪或转储等证据，不能因为一次成功或失败就反转稳定契约。
088 准备上线涉及快照对比的改动时，哪项验收方案最完整？
难度： 实战
- A. 依据“两个快照大小不同就证明存在内存泄漏”完成修改，只要本地运行一次成功就立即发布。
- B. 依据“在相似负载阶段比较多次快照比只看单次对象数量更能发现持续增长类型”实现，在“采集之间必须记录流量、缓存预热和业务状态，否则差异可能合理”成立的环境中验证，并为“缓存预热后对象数量上升”保留可观测证据和回退条件。
- C. 按照“在相似负载阶段比较多次快照比只看单次对象数量更能发现持续增长类型”修改代码，但不核对“采集之间必须记录流量、缓存预热和业务状态，否则差异可能合理”或目标发布模式。
- D. 只验证“采集之间必须记录流量、缓存预热和业务状态，否则差异可能合理”，实现仍继续依赖“两个快照大小不同就证明存在内存泄漏”这一未经证明的假设。
查看答案与解析
正确答案B
完整验收必须同时覆盖规则、边界和生产证据：实现遵守“在相似负载阶段比较多次快照比只看单次对象数量更能发现持续增长类型”，部署环境满足“采集之间必须记录流量、缓存预热和业务状态，否则差异可能合理”，并能在“缓存预热后对象数量上升”出现时定位和回退。其余方案分别依赖错误假设、遗漏环境验证或只检查边界却保留错误实现，均不能证明改动在生产环境中安全。
089 关于GC 根，哪一项准确描述了应依赖的平台契约？
难度： 基础
- A. GC 会忽略事件和委托形成的强引用
- B. 找到根后还需判断该引用是否违反预期生命周期
- C. 对象只要可从静态字段、线程、句柄等 GC 根到达就不会被当作垃圾回收
- D. 只要观察到“短生命周期订阅者被单例发布者保活”，就能把这次现象视为所有环境中的固定行为。
查看答案与解析
正确答案C
正确项给出了GC 根可直接依赖的规则：“对象只要可从静态字段、线程、句柄等 GC 根到达就不会被当作垃圾回收”。“找到根后还需判断该引用是否违反预期生命周期”是应用规则前必须确认的边界，不是规则本身；“GC 会忽略事件和委托形成的强引用”则把常见现象或实现细节扩大成了平台保证。场景“短生命周期订阅者被单例发布者保活”只能作为排查线索，仍需结合目标框架、发布方式和运行时证据验证。
090 生产环境出现“短生命周期订阅者被单例发布者保活”时，针对GC 根应如何排查？
难度： 进阶
- A. 先验证“找到根后还需判断该引用是否违反预期生命周期”，再使用运行时指标、日志或最小复现检查“对象只要可从静态字段、线程、句柄等 GC 根到达就不会被当作垃圾回收”是否成立。
- B. 直接采用“GC 会忽略事件和委托形成的强引用”解释现象，不再收集目标进程和发布配置证据。
- C. 只增加机器资源或重启进程，以一次恢复结果代替对“找到根后还需判断该引用是否违反预期生命周期”的验证。
- D. 只检查代码是否能够编译，通过后便认定“对象只要可从静态字段、线程、句柄等 GC 根到达就不会被当作垃圾回收”在当前部署中必然成立。
查看答案与解析
正确答案A
“短生命周期订阅者被单例发布者保活”可能由多条路径造成，不能直接证明根因。合理顺序是先确认边界“找到根后还需判断该引用是否违反预期生命周期”，再以“对象只要可从静态字段、线程、句柄等 GC 根到达就不会被当作垃圾回收”组织证据。采用误区“GC 会忽略事件和委托形成的强引用”、盲目扩容或只看编译结果，都跳过了运行配置与真实调用路径，无法形成可复核的诊断结论。
091 评审GC 根相关实现时，以下哪项判断不成立？
难度： 实战
- A. 对象只要可从静态字段、线程、句柄等 GC 根到达就不会被当作垃圾回收
- B. GC 会忽略事件和委托形成的强引用
- C. 找到根后还需判断该引用是否违反预期生命周期
- D. 遇到“短生命周期订阅者被单例发布者保活”时，应把可观察证据与平台契约分开记录，再验证二者是否一致。
查看答案与解析
正确答案B
题目要求找出不成立的判断，“GC 会忽略事件和委托形成的强引用”正是GC 根的典型误区。主规则“对象只要可从静态字段、线程、句柄等 GC 根到达就不会被当作垃圾回收”描述了实现应依赖的契约，边界“找到根后还需判断该引用是否违反预期生命周期”限制了结论的适用范围。生产场景还需要保留指标、日志、跟踪或转储等证据，不能因为一次成功或失败就反转稳定契约。
092 准备上线涉及GC 根的改动时，哪项验收方案最完整？
难度： 实战
- A. 依据“GC 会忽略事件和委托形成的强引用”完成修改，只要本地运行一次成功就立即发布。
- B. 按照“对象只要可从静态字段、线程、句柄等 GC 根到达就不会被当作垃圾回收”修改代码，但不核对“找到根后还需判断该引用是否违反预期生命周期”或目标发布模式。
- C. 只验证“找到根后还需判断该引用是否违反预期生命周期”，实现仍继续依赖“GC 会忽略事件和委托形成的强引用”这一未经证明的假设。
- D. 依据“对象只要可从静态字段、线程、句柄等 GC 根到达就不会被当作垃圾回收”实现，在“找到根后还需判断该引用是否违反预期生命周期”成立的环境中验证，并为“短生命周期订阅者被单例发布者保活”保留可观测证据和回退条件。
查看答案与解析
正确答案D
完整验收必须同时覆盖规则、边界和生产证据：实现遵守“对象只要可从静态字段、线程、句柄等 GC 根到达就不会被当作垃圾回收”，部署环境满足“找到根后还需判断该引用是否违反预期生命周期”，并能在“短生命周期订阅者被单例发布者保活”出现时定位和回退。其余方案分别依赖错误假设、遗漏环境验证或只检查边界却保留错误实现，均不能证明改动在生产环境中安全。
093 关于托管与本机内存，哪一项准确描述了应依赖的平台契约？
难度： 基础
- A. 任务管理器内存数值等于 GC Heap Size
- B. 托管堆下降不保证操作系统立即看到相同幅度的工作集下降
- C. 只要观察到“RSS 很高但 GC heap 较小”，就能把这次现象视为所有环境中的固定行为。
- D. 进程内存包含托管堆、JIT 代码、本机堆、线程栈、映射文件等多类区域
查看答案与解析
正确答案D
正确项给出了托管与本机内存可直接依赖的规则：“进程内存包含托管堆、JIT 代码、本机堆、线程栈、映射文件等多类区域”。“托管堆下降不保证操作系统立即看到相同幅度的工作集下降”是应用规则前必须确认的边界，不是规则本身；“任务管理器内存数值等于 GC Heap Size”则把常见现象或实现细节扩大成了平台保证。场景“RSS 很高但 GC heap 较小”只能作为排查线索，仍需结合目标框架、发布方式和运行时证据验证。
094 生产环境出现“RSS 很高但 GC heap 较小”时，针对托管与本机内存应如何排查？
难度： 进阶
- A. 先验证“托管堆下降不保证操作系统立即看到相同幅度的工作集下降”，再使用运行时指标、日志或最小复现检查“进程内存包含托管堆、JIT 代码、本机堆、线程栈、映射文件等多类区域”是否成立。
- B. 直接采用“任务管理器内存数值等于 GC Heap Size”解释现象，不再收集目标进程和发布配置证据。
- C. 只增加机器资源或重启进程，以一次恢复结果代替对“托管堆下降不保证操作系统立即看到相同幅度的工作集下降”的验证。
- D. 只检查代码是否能够编译，通过后便认定“进程内存包含托管堆、JIT 代码、本机堆、线程栈、映射文件等多类区域”在当前部署中必然成立。
查看答案与解析
正确答案A
“RSS 很高但 GC heap 较小”可能由多条路径造成，不能直接证明根因。合理顺序是先确认边界“托管堆下降不保证操作系统立即看到相同幅度的工作集下降”，再以“进程内存包含托管堆、JIT 代码、本机堆、线程栈、映射文件等多类区域”组织证据。采用误区“任务管理器内存数值等于 GC Heap Size”、盲目扩容或只看编译结果，都跳过了运行配置与真实调用路径，无法形成可复核的诊断结论。
095 评审托管与本机内存相关实现时，以下哪项判断不成立？
难度： 实战
- A. 进程内存包含托管堆、JIT 代码、本机堆、线程栈、映射文件等多类区域
- B. 托管堆下降不保证操作系统立即看到相同幅度的工作集下降
- C. 任务管理器内存数值等于 GC Heap Size
- D. 遇到“RSS 很高但 GC heap 较小”时，应把可观察证据与平台契约分开记录，再验证二者是否一致。
查看答案与解析
正确答案C
题目要求找出不成立的判断，“任务管理器内存数值等于 GC Heap Size”正是托管与本机内存的典型误区。主规则“进程内存包含托管堆、JIT 代码、本机堆、线程栈、映射文件等多类区域”描述了实现应依赖的契约，边界“托管堆下降不保证操作系统立即看到相同幅度的工作集下降”限制了结论的适用范围。生产场景还需要保留指标、日志、跟踪或转储等证据，不能因为一次成功或失败就反转稳定契约。
096 准备上线涉及托管与本机内存的改动时，哪项验收方案最完整？
难度： 实战
- A. 依据“任务管理器内存数值等于 GC Heap Size”完成修改，只要本地运行一次成功就立即发布。
- B. 依据“进程内存包含托管堆、JIT 代码、本机堆、线程栈、映射文件等多类区域”实现，在“托管堆下降不保证操作系统立即看到相同幅度的工作集下降”成立的环境中验证，并为“RSS 很高但 GC heap 较小”保留可观测证据和回退条件。
- C. 按照“进程内存包含托管堆、JIT 代码、本机堆、线程栈、映射文件等多类区域”修改代码，但不核对“托管堆下降不保证操作系统立即看到相同幅度的工作集下降”或目标发布模式。
- D. 只验证“托管堆下降不保证操作系统立即看到相同幅度的工作集下降”，实现仍继续依赖“任务管理器内存数值等于 GC Heap Size”这一未经证明的假设。
查看答案与解析
正确答案B
完整验收必须同时覆盖规则、边界和生产证据：实现遵守“进程内存包含托管堆、JIT 代码、本机堆、线程栈、映射文件等多类区域”，部署环境满足“托管堆下降不保证操作系统立即看到相同幅度的工作集下降”，并能在“RSS 很高但 GC heap 较小”出现时定位和回退。其余方案分别依赖错误假设、遗漏环境验证或只检查边界却保留错误实现，均不能证明改动在生产环境中安全。
097 关于泄漏修复验证，哪一项准确描述了应依赖的平台契约？
难度： 基础
- A. 修复后应在可重复负载下观察对象增长斜率、根路径和回收后的稳定水平
- B. 在定时器中调用 GC.Collect 就能解决所有托管泄漏
- C. 强制 GC 只能辅助实验，不能作为生产修复方案
- D. 只要观察到“手工 GC 后内存短暂下降又增长”，就能把这次现象视为所有环境中的固定行为。
查看答案与解析
正确答案A
正确项给出了泄漏修复验证可直接依赖的规则：“修复后应在可重复负载下观察对象增长斜率、根路径和回收后的稳定水平”。“强制 GC 只能辅助实验，不能作为生产修复方案”是应用规则前必须确认的边界，不是规则本身；“在定时器中调用 GC.Collect 就能解决所有托管泄漏”则把常见现象或实现细节扩大成了平台保证。场景“手工 GC 后内存短暂下降又增长”只能作为排查线索，仍需结合目标框架、发布方式和运行时证据验证。
098 生产环境出现“手工 GC 后内存短暂下降又增长”时，针对泄漏修复验证应如何排查？
难度： 进阶
- A. 直接采用“在定时器中调用 GC.Collect 就能解决所有托管泄漏”解释现象，不再收集目标进程和发布配置证据。
- B. 只增加机器资源或重启进程，以一次恢复结果代替对“强制 GC 只能辅助实验，不能作为生产修复方案”的验证。
- C. 先验证“强制 GC 只能辅助实验，不能作为生产修复方案”，再使用运行时指标、日志或最小复现检查“修复后应在可重复负载下观察对象增长斜率、根路径和回收后的稳定水平”是否成立。
- D. 只检查代码是否能够编译，通过后便认定“修复后应在可重复负载下观察对象增长斜率、根路径和回收后的稳定水平”在当前部署中必然成立。
查看答案与解析
正确答案C
“手工 GC 后内存短暂下降又增长”可能由多条路径造成，不能直接证明根因。合理顺序是先确认边界“强制 GC 只能辅助实验，不能作为生产修复方案”，再以“修复后应在可重复负载下观察对象增长斜率、根路径和回收后的稳定水平”组织证据。采用误区“在定时器中调用 GC.Collect 就能解决所有托管泄漏”、盲目扩容或只看编译结果，都跳过了运行配置与真实调用路径，无法形成可复核的诊断结论。
099 评审泄漏修复验证相关实现时，以下哪项判断不成立？
难度： 实战
- A. 修复后应在可重复负载下观察对象增长斜率、根路径和回收后的稳定水平
- B. 在定时器中调用 GC.Collect 就能解决所有托管泄漏
- C. 强制 GC 只能辅助实验，不能作为生产修复方案
- D. 遇到“手工 GC 后内存短暂下降又增长”时，应把可观察证据与平台契约分开记录，再验证二者是否一致。
查看答案与解析
正确答案B
题目要求找出不成立的判断，“在定时器中调用 GC.Collect 就能解决所有托管泄漏”正是泄漏修复验证的典型误区。主规则“修复后应在可重复负载下观察对象增长斜率、根路径和回收后的稳定水平”描述了实现应依赖的契约，边界“强制 GC 只能辅助实验，不能作为生产修复方案”限制了结论的适用范围。生产场景还需要保留指标、日志、跟踪或转储等证据，不能因为一次成功或失败就反转稳定契约。
100 准备上线涉及泄漏修复验证的改动时，哪项验收方案最完整？
难度： 实战
- A. 依据“在定时器中调用 GC.Collect 就能解决所有托管泄漏”完成修改，只要本地运行一次成功就立即发布。
- B. 按照“修复后应在可重复负载下观察对象增长斜率、根路径和回收后的稳定水平”修改代码，但不核对“强制 GC 只能辅助实验，不能作为生产修复方案”或目标发布模式。
- C. 只验证“强制 GC 只能辅助实验，不能作为生产修复方案”，实现仍继续依赖“在定时器中调用 GC.Collect 就能解决所有托管泄漏”这一未经证明的假设。
- D. 依据“修复后应在可重复负载下观察对象增长斜率、根路径和回收后的稳定水平”实现，在“强制 GC 只能辅助实验，不能作为生产修复方案”成立的环境中验证，并为“手工 GC 后内存短暂下降又增长”保留可观测证据和回退条件。
查看答案与解析
正确答案D
完整验收必须同时覆盖规则、边界和生产证据：实现遵守“修复后应在可重复负载下观察对象增长斜率、根路径和回收后的稳定水平”，部署环境满足“强制 GC 只能辅助实验，不能作为生产修复方案”，并能在“手工 GC 后内存短暂下降又增长”出现时定位和回退。其余方案分别依赖错误假设、遗漏环境验证或只检查边界却保留错误实现，均不能证明改动在生产环境中安全。