.NET 运行时试题 07：Server GC、Workstation GC 与延迟模式
121 关于Server GC，哪一项准确描述了应依赖的平台契约？
难度： 基础
- A. Server GC 在任何小型进程中都必然延迟最低
- B. 容器 CPU 和内存限制会影响实际效果，不能只按宿主机核数推断
- C. 只要观察到“容器内 GC 堆数量与预期不一致”，就能把这次现象视为所有环境中的固定行为。
- D. Server GC 面向高吞吐服务器场景，可使用多个堆并让回收工作与处理器资源配合
查看答案与解析
正确答案D
正确项给出了Server GC可直接依赖的规则：“Server GC 面向高吞吐服务器场景，可使用多个堆并让回收工作与处理器资源配合”。“容器 CPU 和内存限制会影响实际效果，不能只按宿主机核数推断”是应用规则前必须确认的边界，不是规则本身；“Server GC 在任何小型进程中都必然延迟最低”则把常见现象或实现细节扩大成了平台保证。场景“容器内 GC 堆数量与预期不一致”只能作为排查线索，仍需结合目标框架、发布方式和运行时证据验证。
122 生产环境出现“容器内 GC 堆数量与预期不一致”时，针对Server GC应如何排查？
难度： 进阶
- A. 直接采用“Server GC 在任何小型进程中都必然延迟最低”解释现象，不再收集目标进程和发布配置证据。
- B. 只增加机器资源或重启进程，以一次恢复结果代替对“容器 CPU 和内存限制会影响实际效果，不能只按宿主机核数推断”的验证。
- C. 先验证“容器 CPU 和内存限制会影响实际效果，不能只按宿主机核数推断”，再使用运行时指标、日志或最小复现检查“Server GC 面向高吞吐服务器场景，可使用多个堆并让回收工作与处理器资源配合”是否成立。
- D. 只检查代码是否能够编译，通过后便认定“Server GC 面向高吞吐服务器场景，可使用多个堆并让回收工作与处理器资源配合”在当前部署中必然成立。
查看答案与解析
正确答案C
“容器内 GC 堆数量与预期不一致”可能由多条路径造成，不能直接证明根因。合理顺序是先确认边界“容器 CPU 和内存限制会影响实际效果，不能只按宿主机核数推断”，再以“Server GC 面向高吞吐服务器场景，可使用多个堆并让回收工作与处理器资源配合”组织证据。采用误区“Server GC 在任何小型进程中都必然延迟最低”、盲目扩容或只看编译结果，都跳过了运行配置与真实调用路径，无法形成可复核的诊断结论。
123 评审Server GC相关实现时，以下哪项判断不成立？
难度： 实战
- A. Server GC 面向高吞吐服务器场景，可使用多个堆并让回收工作与处理器资源配合
- B. Server GC 在任何小型进程中都必然延迟最低
- C. 容器 CPU 和内存限制会影响实际效果，不能只按宿主机核数推断
- D. 遇到“容器内 GC 堆数量与预期不一致”时，应把可观察证据与平台契约分开记录，再验证二者是否一致。
查看答案与解析
正确答案B
题目要求找出不成立的判断，“Server GC 在任何小型进程中都必然延迟最低”正是Server GC的典型误区。主规则“Server GC 面向高吞吐服务器场景，可使用多个堆并让回收工作与处理器资源配合”描述了实现应依赖的契约，边界“容器 CPU 和内存限制会影响实际效果，不能只按宿主机核数推断”限制了结论的适用范围。生产场景还需要保留指标、日志、跟踪或转储等证据，不能因为一次成功或失败就反转稳定契约。
124 准备上线涉及Server GC的改动时，哪项验收方案最完整？
难度： 实战
- A. 依据“Server GC 面向高吞吐服务器场景，可使用多个堆并让回收工作与处理器资源配合”实现，在“容器 CPU 和内存限制会影响实际效果，不能只按宿主机核数推断”成立的环境中验证，并为“容器内 GC 堆数量与预期不一致”保留可观测证据和回退条件。
- B. 依据“Server GC 在任何小型进程中都必然延迟最低”完成修改，只要本地运行一次成功就立即发布。
- C. 按照“Server GC 面向高吞吐服务器场景，可使用多个堆并让回收工作与处理器资源配合”修改代码，但不核对“容器 CPU 和内存限制会影响实际效果，不能只按宿主机核数推断”或目标发布模式。
- D. 只验证“容器 CPU 和内存限制会影响实际效果，不能只按宿主机核数推断”，实现仍继续依赖“Server GC 在任何小型进程中都必然延迟最低”这一未经证明的假设。
查看答案与解析
正确答案A
完整验收必须同时覆盖规则、边界和生产证据：实现遵守“Server GC 面向高吞吐服务器场景，可使用多个堆并让回收工作与处理器资源配合”，部署环境满足“容器 CPU 和内存限制会影响实际效果，不能只按宿主机核数推断”，并能在“容器内 GC 堆数量与预期不一致”出现时定位和回退。其余方案分别依赖错误假设、遗漏环境验证或只检查边界却保留错误实现，均不能证明改动在生产环境中安全。
125 关于Workstation GC，哪一项准确描述了应依赖的平台契约？
难度： 基础
- A. Workstation GC 只能用于桌面 UI 应用
- B. Workstation GC 更关注交互式或客户端工作负载的响应特征，并可配合后台回收
- C. 具体模式仍受运行时配置和宿主方式影响
- D. 只要观察到“后台工具使用默认 GC 模式运行”，就能把这次现象视为所有环境中的固定行为。
查看答案与解析
正确答案B
正确项给出了Workstation GC可直接依赖的规则：“Workstation GC 更关注交互式或客户端工作负载的响应特征，并可配合后台回收”。“具体模式仍受运行时配置和宿主方式影响”是应用规则前必须确认的边界，不是规则本身；“Workstation GC 只能用于桌面 UI 应用”则把常见现象或实现细节扩大成了平台保证。场景“后台工具使用默认 GC 模式运行”只能作为排查线索，仍需结合目标框架、发布方式和运行时证据验证。
126 生产环境出现“后台工具使用默认 GC 模式运行”时，针对Workstation GC应如何排查？
难度： 进阶
- A. 先验证“具体模式仍受运行时配置和宿主方式影响”，再使用运行时指标、日志或最小复现检查“Workstation GC 更关注交互式或客户端工作负载的响应特征，并可配合后台回收”是否成立。
- B. 直接采用“Workstation GC 只能用于桌面 UI 应用”解释现象，不再收集目标进程和发布配置证据。
- C. 只增加机器资源或重启进程，以一次恢复结果代替对“具体模式仍受运行时配置和宿主方式影响”的验证。
- D. 只检查代码是否能够编译，通过后便认定“Workstation GC 更关注交互式或客户端工作负载的响应特征，并可配合后台回收”在当前部署中必然成立。
查看答案与解析
正确答案A
“后台工具使用默认 GC 模式运行”可能由多条路径造成，不能直接证明根因。合理顺序是先确认边界“具体模式仍受运行时配置和宿主方式影响”，再以“Workstation GC 更关注交互式或客户端工作负载的响应特征，并可配合后台回收”组织证据。采用误区“Workstation GC 只能用于桌面 UI 应用”、盲目扩容或只看编译结果，都跳过了运行配置与真实调用路径，无法形成可复核的诊断结论。
127 评审Workstation GC相关实现时，以下哪项判断不成立？
难度： 实战
- A. Workstation GC 更关注交互式或客户端工作负载的响应特征，并可配合后台回收
- B. 具体模式仍受运行时配置和宿主方式影响
- C. Workstation GC 只能用于桌面 UI 应用
- D. 遇到“后台工具使用默认 GC 模式运行”时，应把可观察证据与平台契约分开记录，再验证二者是否一致。
查看答案与解析
正确答案C
题目要求找出不成立的判断，“Workstation GC 只能用于桌面 UI 应用”正是Workstation GC的典型误区。主规则“Workstation GC 更关注交互式或客户端工作负载的响应特征，并可配合后台回收”描述了实现应依赖的契约，边界“具体模式仍受运行时配置和宿主方式影响”限制了结论的适用范围。生产场景还需要保留指标、日志、跟踪或转储等证据，不能因为一次成功或失败就反转稳定契约。
128 准备上线涉及Workstation GC的改动时，哪项验收方案最完整？
难度： 实战
- A. 依据“Workstation GC 只能用于桌面 UI 应用”完成修改，只要本地运行一次成功就立即发布。
- B. 按照“Workstation GC 更关注交互式或客户端工作负载的响应特征，并可配合后台回收”修改代码，但不核对“具体模式仍受运行时配置和宿主方式影响”或目标发布模式。
- C. 只验证“具体模式仍受运行时配置和宿主方式影响”，实现仍继续依赖“Workstation GC 只能用于桌面 UI 应用”这一未经证明的假设。
- D. 依据“Workstation GC 更关注交互式或客户端工作负载的响应特征，并可配合后台回收”实现，在“具体模式仍受运行时配置和宿主方式影响”成立的环境中验证，并为“后台工具使用默认 GC 模式运行”保留可观测证据和回退条件。
查看答案与解析
正确答案D
完整验收必须同时覆盖规则、边界和生产证据：实现遵守“Workstation GC 更关注交互式或客户端工作负载的响应特征，并可配合后台回收”，部署环境满足“具体模式仍受运行时配置和宿主方式影响”，并能在“后台工具使用默认 GC 模式运行”出现时定位和回退。其余方案分别依赖错误假设、遗漏环境验证或只检查边界却保留错误实现，均不能证明改动在生产环境中安全。
129 关于后台 GC，哪一项准确描述了应依赖的平台契约？
难度： 基础
- A. 开启后台 GC 后应用线程永远不会因 GC 暂停
- B. 某些阶段仍需要暂停托管线程，并发不代表零停顿
- C. 后台 GC 允许部分高代回收与托管线程并发进行，以缩短长时间完全暂停的影响
- D. 只要观察到“延迟曲线仍出现短暂停顿”，就能把这次现象视为所有环境中的固定行为。
查看答案与解析
正确答案C
正确项给出了后台 GC可直接依赖的规则：“后台 GC 允许部分高代回收与托管线程并发进行，以缩短长时间完全暂停的影响”。“某些阶段仍需要暂停托管线程，并发不代表零停顿”是应用规则前必须确认的边界，不是规则本身；“开启后台 GC 后应用线程永远不会因 GC 暂停”则把常见现象或实现细节扩大成了平台保证。场景“延迟曲线仍出现短暂停顿”只能作为排查线索，仍需结合目标框架、发布方式和运行时证据验证。
130 生产环境出现“延迟曲线仍出现短暂停顿”时，针对后台 GC应如何排查？
难度： 进阶
- A. 先验证“某些阶段仍需要暂停托管线程，并发不代表零停顿”，再使用运行时指标、日志或最小复现检查“后台 GC 允许部分高代回收与托管线程并发进行，以缩短长时间完全暂停的影响”是否成立。
- B. 直接采用“开启后台 GC 后应用线程永远不会因 GC 暂停”解释现象，不再收集目标进程和发布配置证据。
- C. 只增加机器资源或重启进程，以一次恢复结果代替对“某些阶段仍需要暂停托管线程，并发不代表零停顿”的验证。
- D. 只检查代码是否能够编译，通过后便认定“后台 GC 允许部分高代回收与托管线程并发进行，以缩短长时间完全暂停的影响”在当前部署中必然成立。
查看答案与解析
正确答案A
“延迟曲线仍出现短暂停顿”可能由多条路径造成，不能直接证明根因。合理顺序是先确认边界“某些阶段仍需要暂停托管线程，并发不代表零停顿”，再以“后台 GC 允许部分高代回收与托管线程并发进行，以缩短长时间完全暂停的影响”组织证据。采用误区“开启后台 GC 后应用线程永远不会因 GC 暂停”、盲目扩容或只看编译结果，都跳过了运行配置与真实调用路径，无法形成可复核的诊断结论。
131 评审后台 GC相关实现时，以下哪项判断不成立？
难度： 实战
- A. 后台 GC 允许部分高代回收与托管线程并发进行，以缩短长时间完全暂停的影响
- B. 某些阶段仍需要暂停托管线程，并发不代表零停顿
- C. 遇到“延迟曲线仍出现短暂停顿”时，应把可观察证据与平台契约分开记录，再验证二者是否一致。
- D. 开启后台 GC 后应用线程永远不会因 GC 暂停
查看答案与解析
正确答案D
题目要求找出不成立的判断，“开启后台 GC 后应用线程永远不会因 GC 暂停”正是后台 GC的典型误区。主规则“后台 GC 允许部分高代回收与托管线程并发进行，以缩短长时间完全暂停的影响”描述了实现应依赖的契约，边界“某些阶段仍需要暂停托管线程，并发不代表零停顿”限制了结论的适用范围。生产场景还需要保留指标、日志、跟踪或转储等证据，不能因为一次成功或失败就反转稳定契约。
132 准备上线涉及后台 GC的改动时，哪项验收方案最完整？
难度： 实战
- A. 依据“开启后台 GC 后应用线程永远不会因 GC 暂停”完成修改，只要本地运行一次成功就立即发布。
- B. 依据“后台 GC 允许部分高代回收与托管线程并发进行，以缩短长时间完全暂停的影响”实现，在“某些阶段仍需要暂停托管线程，并发不代表零停顿”成立的环境中验证，并为“延迟曲线仍出现短暂停顿”保留可观测证据和回退条件。
- C. 按照“后台 GC 允许部分高代回收与托管线程并发进行，以缩短长时间完全暂停的影响”修改代码，但不核对“某些阶段仍需要暂停托管线程，并发不代表零停顿”或目标发布模式。
- D. 只验证“某些阶段仍需要暂停托管线程，并发不代表零停顿”，实现仍继续依赖“开启后台 GC 后应用线程永远不会因 GC 暂停”这一未经证明的假设。
查看答案与解析
正确答案B
完整验收必须同时覆盖规则、边界和生产证据：实现遵守“后台 GC 允许部分高代回收与托管线程并发进行，以缩短长时间完全暂停的影响”，部署环境满足“某些阶段仍需要暂停托管线程，并发不代表零停顿”，并能在“延迟曲线仍出现短暂停顿”出现时定位和回退。其余方案分别依赖错误假设、遗漏环境验证或只检查边界却保留错误实现，均不能证明改动在生产环境中安全。
133 关于低延迟模式，哪一项准确描述了应依赖的平台契约？
难度： 基础
- A. SustainedLowLatency 会永久禁止所有 Gen 2 回收
- B. 必须限制使用窗口并准备内存上限，不能长期当成性能开关
- C. 只要观察到“实时处理窗口内减少高代回收”，就能把这次现象视为所有环境中的固定行为。
- D. GC 延迟模式可在受控时间窗口调整回收取舍，但会增加内存压力或延后完整回收
查看答案与解析
正确答案D
正确项给出了低延迟模式可直接依赖的规则：“GC 延迟模式可在受控时间窗口调整回收取舍，但会增加内存压力或延后完整回收”。“必须限制使用窗口并准备内存上限，不能长期当成性能开关”是应用规则前必须确认的边界，不是规则本身；“SustainedLowLatency 会永久禁止所有 Gen 2 回收”则把常见现象或实现细节扩大成了平台保证。场景“实时处理窗口内减少高代回收”只能作为排查线索，仍需结合目标框架、发布方式和运行时证据验证。
134 生产环境出现“实时处理窗口内减少高代回收”时，针对低延迟模式应如何排查？
难度： 进阶
- A. 直接采用“SustainedLowLatency 会永久禁止所有 Gen 2 回收”解释现象，不再收集目标进程和发布配置证据。
- B. 先验证“必须限制使用窗口并准备内存上限，不能长期当成性能开关”，再使用运行时指标、日志或最小复现检查“GC 延迟模式可在受控时间窗口调整回收取舍，但会增加内存压力或延后完整回收”是否成立。
- C. 只增加机器资源或重启进程，以一次恢复结果代替对“必须限制使用窗口并准备内存上限，不能长期当成性能开关”的验证。
- D. 只检查代码是否能够编译，通过后便认定“GC 延迟模式可在受控时间窗口调整回收取舍，但会增加内存压力或延后完整回收”在当前部署中必然成立。
查看答案与解析
正确答案B
“实时处理窗口内减少高代回收”可能由多条路径造成，不能直接证明根因。合理顺序是先确认边界“必须限制使用窗口并准备内存上限，不能长期当成性能开关”，再以“GC 延迟模式可在受控时间窗口调整回收取舍，但会增加内存压力或延后完整回收”组织证据。采用误区“SustainedLowLatency 会永久禁止所有 Gen 2 回收”、盲目扩容或只看编译结果，都跳过了运行配置与真实调用路径，无法形成可复核的诊断结论。
135 评审低延迟模式相关实现时，以下哪项判断不成立？
难度： 实战
- A. SustainedLowLatency 会永久禁止所有 Gen 2 回收
- B. GC 延迟模式可在受控时间窗口调整回收取舍，但会增加内存压力或延后完整回收
- C. 必须限制使用窗口并准备内存上限，不能长期当成性能开关
- D. 遇到“实时处理窗口内减少高代回收”时，应把可观察证据与平台契约分开记录，再验证二者是否一致。
查看答案与解析
正确答案A
题目要求找出不成立的判断，“SustainedLowLatency 会永久禁止所有 Gen 2 回收”正是低延迟模式的典型误区。主规则“GC 延迟模式可在受控时间窗口调整回收取舍，但会增加内存压力或延后完整回收”描述了实现应依赖的契约，边界“必须限制使用窗口并准备内存上限，不能长期当成性能开关”限制了结论的适用范围。生产场景还需要保留指标、日志、跟踪或转储等证据，不能因为一次成功或失败就反转稳定契约。
136 准备上线涉及低延迟模式的改动时，哪项验收方案最完整？
难度： 实战
- A. 依据“SustainedLowLatency 会永久禁止所有 Gen 2 回收”完成修改，只要本地运行一次成功就立即发布。
- B. 按照“GC 延迟模式可在受控时间窗口调整回收取舍，但会增加内存压力或延后完整回收”修改代码，但不核对“必须限制使用窗口并准备内存上限，不能长期当成性能开关”或目标发布模式。
- C. 依据“GC 延迟模式可在受控时间窗口调整回收取舍，但会增加内存压力或延后完整回收”实现，在“必须限制使用窗口并准备内存上限，不能长期当成性能开关”成立的环境中验证，并为“实时处理窗口内减少高代回收”保留可观测证据和回退条件。
- D. 只验证“必须限制使用窗口并准备内存上限，不能长期当成性能开关”，实现仍继续依赖“SustainedLowLatency 会永久禁止所有 Gen 2 回收”这一未经证明的假设。
查看答案与解析
正确答案C
完整验收必须同时覆盖规则、边界和生产证据：实现遵守“GC 延迟模式可在受控时间窗口调整回收取舍，但会增加内存压力或延后完整回收”，部署环境满足“必须限制使用窗口并准备内存上限，不能长期当成性能开关”，并能在“实时处理窗口内减少高代回收”出现时定位和回退。其余方案分别依赖错误假设、遗漏环境验证或只检查边界却保留错误实现，均不能证明改动在生产环境中安全。
137 关于容器感知，哪一项准确描述了应依赖的平台契约？
难度： 基础
- A. .NET 运行时会考虑容器资源限制来制定部分 GC 和线程策略
- B. 运行在容器里就会自动获得无限制内存保护
- C. 编排平台的 request、limit 与进程可见资源仍需用运行时指标核实
- D. 只要观察到“Pod 接近内存限制却没有明显托管异常”，就能把这次现象视为所有环境中的固定行为。
查看答案与解析
正确答案A
正确项给出了容器感知可直接依赖的规则：“.NET 运行时会考虑容器资源限制来制定部分 GC 和线程策略”。“编排平台的 request、limit 与进程可见资源仍需用运行时指标核实”是应用规则前必须确认的边界，不是规则本身；“运行在容器里就会自动获得无限制内存保护”则把常见现象或实现细节扩大成了平台保证。场景“Pod 接近内存限制却没有明显托管异常”只能作为排查线索，仍需结合目标框架、发布方式和运行时证据验证。
138 生产环境出现“Pod 接近内存限制却没有明显托管异常”时，针对容器感知应如何排查？
难度： 进阶
- A. 直接采用“运行在容器里就会自动获得无限制内存保护”解释现象，不再收集目标进程和发布配置证据。
- B. 只增加机器资源或重启进程，以一次恢复结果代替对“编排平台的 request、limit 与进程可见资源仍需用运行时指标核实”的验证。
- C. 先验证“编排平台的 request、limit 与进程可见资源仍需用运行时指标核实”，再使用运行时指标、日志或最小复现检查“.NET 运行时会考虑容器资源限制来制定部分 GC 和线程策略”是否成立。
- D. 只检查代码是否能够编译，通过后便认定“.NET 运行时会考虑容器资源限制来制定部分 GC 和线程策略”在当前部署中必然成立。
查看答案与解析
正确答案C
“Pod 接近内存限制却没有明显托管异常”可能由多条路径造成，不能直接证明根因。合理顺序是先确认边界“编排平台的 request、limit 与进程可见资源仍需用运行时指标核实”，再以“.NET 运行时会考虑容器资源限制来制定部分 GC 和线程策略”组织证据。采用误区“运行在容器里就会自动获得无限制内存保护”、盲目扩容或只看编译结果，都跳过了运行配置与真实调用路径，无法形成可复核的诊断结论。
139 评审容器感知相关实现时，以下哪项判断不成立？
难度： 实战
- A. .NET 运行时会考虑容器资源限制来制定部分 GC 和线程策略
- B. 编排平台的 request、limit 与进程可见资源仍需用运行时指标核实
- C. 遇到“Pod 接近内存限制却没有明显托管异常”时，应把可观察证据与平台契约分开记录，再验证二者是否一致。
- D. 运行在容器里就会自动获得无限制内存保护
查看答案与解析
正确答案D
题目要求找出不成立的判断，“运行在容器里就会自动获得无限制内存保护”正是容器感知的典型误区。主规则“.NET 运行时会考虑容器资源限制来制定部分 GC 和线程策略”描述了实现应依赖的契约，边界“编排平台的 request、limit 与进程可见资源仍需用运行时指标核实”限制了结论的适用范围。生产场景还需要保留指标、日志、跟踪或转储等证据，不能因为一次成功或失败就反转稳定契约。
140 准备上线涉及容器感知的改动时，哪项验收方案最完整？
难度： 实战
- A. 依据“运行在容器里就会自动获得无限制内存保护”完成修改，只要本地运行一次成功就立即发布。
- B. 依据“.NET 运行时会考虑容器资源限制来制定部分 GC 和线程策略”实现，在“编排平台的 request、limit 与进程可见资源仍需用运行时指标核实”成立的环境中验证，并为“Pod 接近内存限制却没有明显托管异常”保留可观测证据和回退条件。
- C. 按照“.NET 运行时会考虑容器资源限制来制定部分 GC 和线程策略”修改代码，但不核对“编排平台的 request、limit 与进程可见资源仍需用运行时指标核实”或目标发布模式。
- D. 只验证“编排平台的 request、limit 与进程可见资源仍需用运行时指标核实”，实现仍继续依赖“运行在容器里就会自动获得无限制内存保护”这一未经证明的假设。
查看答案与解析
正确答案B
完整验收必须同时覆盖规则、边界和生产证据：实现遵守“.NET 运行时会考虑容器资源限制来制定部分 GC 和线程策略”，部署环境满足“编排平台的 request、limit 与进程可见资源仍需用运行时指标核实”，并能在“Pod 接近内存限制却没有明显托管异常”出现时定位和回退。其余方案分别依赖错误假设、遗漏环境验证或只检查边界却保留错误实现，均不能证明改动在生产环境中安全。