ASP.NET Core 试题 50：性能与故障排查综合
0981 在 同步阻塞 的框架契约中，哪项是应直接依赖的主规则？
难度： 基础
- A. 把同步方法包装为 async 关键字就会释放线程
- B. 异步必须贯穿可等待 I/O；CPU 密集任务应限并发或移出请求，而不是盲目 Task.Run
- C. 在请求热路径调用 .Result、Wait 或同步 I/O 会占用线程并可能造成线程池饥饿
- D. 观察到“吞吐下降且线程池线程数持续爬升”即可把一次现象当成完整框架契约。
查看答案与解析
正确答案C
正确答案直接描述 同步阻塞 的主规则：在请求热路径调用 .Result、Wait 或同步 I/O 会占用线程并可能造成线程池饥饿。选项“异步必须贯穿可等待 I/O；CPU 密集任务应限并发或移出请求，而不是盲目 Task.Run”是使用规则时要验证的边界，不是规则本身；“把同步方法包装为 async 关键字就会释放线程”则是会导致错误实现的典型误区。场景只能提供线索，不能替代框架契约。
0982 吞吐下降且线程池线程数持续爬升。排查时哪项动作最合理？
难度： 进阶
- A. 直接按“把同步方法包装为 async 关键字就会释放线程”定性，不再检查配置、身份或运行时证据。
- B. 先验证“异步必须贯穿可等待 I/O；CPU 密集任务应限并发或移出请求，而不是盲目 Task.Run”，再依据“在请求热路径调用 .Result、Wait 或同步 I/O 会占用线程并可能造成线程池饥饿”判断实现是否符合契约。
- C. 只增加重试次数或机器资源，暂不核对“异步必须贯穿可等待 I/O；CPU 密集任务应限并发或移出请求，而不是盲目 Task.Run”。
- D. 以一次成功请求作为结论，不再确认“在请求热路径调用 .Result、Wait 或同步 I/O 会占用线程并可能造成线程池饥饿”是否成立。
查看答案与解析
正确答案B
场景“吞吐下降且线程池线程数持续爬升”指向 同步阻塞，但症状本身不能证明根因。正确排查应先确认边界“异步必须贯穿可等待 I/O；CPU 密集任务应限并发或移出请求，而不是盲目 Task.Run”，再用主规则“在请求热路径调用 .Result、Wait 或同步 I/O 会占用线程并可能造成线程池饥饿”解释证据。直接采用误区“把同步方法包装为 async 关键字就会释放线程”、只扩容或依赖一次成功都会掩盖真实配置和请求路径。
0983 关于 同步阻塞，以下哪项说法不成立？
难度： 实战
- A. 把同步方法包装为 async 关键字就会释放线程
- B. 在请求热路径调用 .Result、Wait 或同步 I/O 会占用线程并可能造成线程池饥饿
- C. 异步必须贯穿可等待 I/O；CPU 密集任务应限并发或移出请求，而不是盲目 Task.Run
- D. 出现“吞吐下降且线程池线程数持续爬升”时，应收集证据并同时核对主规则与适用边界。
查看答案与解析
正确答案A
题目要求选出不成立的说法，答案“把同步方法包装为 async 关键字就会释放线程”正是 同步阻塞 的典型误区。其余三项分别给出了主规则“在请求热路径调用 .Result、Wait 或同步 I/O 会占用线程并可能造成线程池饥饿”、适用边界“异步必须贯穿可等待 I/O；CPU 密集任务应限并发或移出请求，而不是盲目 Task.Run”以及面向场景的正确取证方式，不能因为题干使用否定问法而反选这些有效结论。
0984 针对“吞吐下降且线程池线程数持续爬升”进行上线评审，哪项决策依据最完整？
难度： 实战
- A. 按“把同步方法包装为 async 关键字就会释放线程”修改实现，并把一次请求成功作为验收结果。
- B. 按“在请求热路径调用 .Result、Wait 或同步 I/O 会占用线程并可能造成线程池饥饿”修改代码后直接上线，不验证“异步必须贯穿可等待 I/O；CPU 密集任务应限并发或移出请求，而不是盲目 Task.Run”。
- C. 只验证“异步必须贯穿可等待 I/O；CPU 密集任务应限并发或移出请求，而不是盲目 Task.Run”，但实现仍继续依赖“把同步方法包装为 async 关键字就会释放线程”。
- D. 按“在请求热路径调用 .Result、Wait 或同步 I/O 会占用线程并可能造成线程池饥饿”修正实现，并用测试或遥测验证“异步必须贯穿可等待 I/O；CPU 密集任务应限并发或移出请求，而不是盲目 Task.Run”。
查看答案与解析
正确答案D
完整决策同时覆盖规则与验证：在请求热路径调用 .Result、Wait 或同步 I/O 会占用线程并可能造成线程池饥饿；并确认 异步必须贯穿可等待 I/O；CPU 密集任务应限并发或移出请求，而不是盲目 Task.Run。继续接受“把同步方法包装为 async 关键字就会释放线程”会让评审依据失真；只改代码不验证边界，或只检查边界却沿用误区，都不足以判断“吞吐下降且线程池线程数持续爬升”这一生产场景能否安全上线。
0985 在 分配与 GC 的框架契约中，哪项是应直接依赖的主规则？
难度： 基础
- A. 把所有对象改为 Singleton 就能消除 GC 且没有并发风险
- B. 先用 dotnet-counters、trace 或 profiler 定位分配热点，再选择池化、复用或流式处理
- C. 观察到“优化后出现跨请求状态污染”即可把一次现象当成完整框架契约。
- D. 大对象、频繁临时字符串和无界缓存会增加 GC 压力与暂停
查看答案与解析
正确答案D
正确答案直接描述 分配与 GC 的主规则：大对象、频繁临时字符串和无界缓存会增加 GC 压力与暂停。选项“先用 dotnet-counters、trace 或 profiler 定位分配热点，再选择池化、复用或流式处理”是使用规则时要验证的边界，不是规则本身；“把所有对象改为 Singleton 就能消除 GC 且没有并发风险”则是会导致错误实现的典型误区。场景只能提供线索，不能替代框架契约。
0986 优化后出现跨请求状态污染。排查时哪项动作最合理？
难度： 进阶
- A. 先验证“先用 dotnet-counters、trace 或 profiler 定位分配热点，再选择池化、复用或流式处理”，再依据“大对象、频繁临时字符串和无界缓存会增加 GC 压力与暂停”判断实现是否符合契约。
- B. 直接按“把所有对象改为 Singleton 就能消除 GC 且没有并发风险”定性，不再检查配置、身份或运行时证据。
- C. 只增加重试次数或机器资源，暂不核对“先用 dotnet-counters、trace 或 profiler 定位分配热点，再选择池化、复用或流式处理”。
- D. 以一次成功请求作为结论，不再确认“大对象、频繁临时字符串和无界缓存会增加 GC 压力与暂停”是否成立。
查看答案与解析
正确答案A
场景“优化后出现跨请求状态污染”指向 分配与 GC，但症状本身不能证明根因。正确排查应先确认边界“先用 dotnet-counters、trace 或 profiler 定位分配热点，再选择池化、复用或流式处理”，再用主规则“大对象、频繁临时字符串和无界缓存会增加 GC 压力与暂停”解释证据。直接采用误区“把所有对象改为 Singleton 就能消除 GC 且没有并发风险”、只扩容或依赖一次成功都会掩盖真实配置和请求路径。
0987 关于 分配与 GC，以下哪项说法不成立？
难度： 实战
- A. 大对象、频繁临时字符串和无界缓存会增加 GC 压力与暂停
- B. 先用 dotnet-counters、trace 或 profiler 定位分配热点，再选择池化、复用或流式处理
- C. 把所有对象改为 Singleton 就能消除 GC 且没有并发风险
- D. 出现“优化后出现跨请求状态污染”时，应收集证据并同时核对主规则与适用边界。
查看答案与解析
正确答案C
题目要求选出不成立的说法，答案“把所有对象改为 Singleton 就能消除 GC 且没有并发风险”正是 分配与 GC 的典型误区。其余三项分别给出了主规则“大对象、频繁临时字符串和无界缓存会增加 GC 压力与暂停”、适用边界“先用 dotnet-counters、trace 或 profiler 定位分配热点，再选择池化、复用或流式处理”以及面向场景的正确取证方式，不能因为题干使用否定问法而反选这些有效结论。
0988 针对“优化后出现跨请求状态污染”进行上线评审，哪项决策依据最完整？
难度： 实战
- A. 按“把所有对象改为 Singleton 就能消除 GC 且没有并发风险”修改实现，并把一次请求成功作为验收结果。
- B. 按“大对象、频繁临时字符串和无界缓存会增加 GC 压力与暂停”修正实现，并用测试或遥测验证“先用 dotnet-counters、trace 或 profiler 定位分配热点，再选择池化、复用或流式处理”。
- C. 按“大对象、频繁临时字符串和无界缓存会增加 GC 压力与暂停”修改代码后直接上线，不验证“先用 dotnet-counters、trace 或 profiler 定位分配热点，再选择池化、复用或流式处理”。
- D. 只验证“先用 dotnet-counters、trace 或 profiler 定位分配热点，再选择池化、复用或流式处理”，但实现仍继续依赖“把所有对象改为 Singleton 就能消除 GC 且没有并发风险”。
查看答案与解析
正确答案B
完整决策同时覆盖规则与验证：大对象、频繁临时字符串和无界缓存会增加 GC 压力与暂停；并确认 先用 dotnet-counters、trace 或 profiler 定位分配热点，再选择池化、复用或流式处理。继续接受“把所有对象改为 Singleton 就能消除 GC 且没有并发风险”会让评审依据失真；只改代码不验证边界，或只检查边界却沿用误区，都不足以判断“优化后出现跨请求状态污染”这一生产场景能否安全上线。
0989 在 数据库瓶颈 的框架契约中，哪项是应直接依赖的主规则？
难度： 基础
- A. 慢查询、过量往返、锁等待和连接池耗尽常表现为 API 延迟
- B. 提高 Kestrel 并发限制能修复任何慢 SQL
- C. 应关联请求 Trace、EF 日志和数据库执行计划，先减少查询与数据量再盲目扩容
- D. 观察到“更多请求并发进入后数据库雪崩”即可把一次现象当成完整框架契约。
查看答案与解析
正确答案A
正确答案直接描述 数据库瓶颈 的主规则：慢查询、过量往返、锁等待和连接池耗尽常表现为 API 延迟。选项“应关联请求 Trace、EF 日志和数据库执行计划，先减少查询与数据量再盲目扩容”是使用规则时要验证的边界，不是规则本身；“提高 Kestrel 并发限制能修复任何慢 SQL”则是会导致错误实现的典型误区。场景只能提供线索，不能替代框架契约。
0990 更多请求并发进入后数据库雪崩。排查时哪项动作最合理？
难度： 进阶
- A. 直接按“提高 Kestrel 并发限制能修复任何慢 SQL”定性，不再检查配置、身份或运行时证据。
- B. 先验证“应关联请求 Trace、EF 日志和数据库执行计划，先减少查询与数据量再盲目扩容”，再依据“慢查询、过量往返、锁等待和连接池耗尽常表现为 API 延迟”判断实现是否符合契约。
- C. 只增加重试次数或机器资源，暂不核对“应关联请求 Trace、EF 日志和数据库执行计划，先减少查询与数据量再盲目扩容”。
- D. 以一次成功请求作为结论，不再确认“慢查询、过量往返、锁等待和连接池耗尽常表现为 API 延迟”是否成立。
查看答案与解析
正确答案B
场景“更多请求并发进入后数据库雪崩”指向 数据库瓶颈，但症状本身不能证明根因。正确排查应先确认边界“应关联请求 Trace、EF 日志和数据库执行计划，先减少查询与数据量再盲目扩容”，再用主规则“慢查询、过量往返、锁等待和连接池耗尽常表现为 API 延迟”解释证据。直接采用误区“提高 Kestrel 并发限制能修复任何慢 SQL”、只扩容或依赖一次成功都会掩盖真实配置和请求路径。
0991 关于 数据库瓶颈，以下哪项说法不成立？
难度： 实战
- A. 慢查询、过量往返、锁等待和连接池耗尽常表现为 API 延迟
- B. 应关联请求 Trace、EF 日志和数据库执行计划，先减少查询与数据量再盲目扩容
- C. 提高 Kestrel 并发限制能修复任何慢 SQL
- D. 出现“更多请求并发进入后数据库雪崩”时，应收集证据并同时核对主规则与适用边界。
查看答案与解析
正确答案C
题目要求选出不成立的说法，答案“提高 Kestrel 并发限制能修复任何慢 SQL”正是 数据库瓶颈 的典型误区。其余三项分别给出了主规则“慢查询、过量往返、锁等待和连接池耗尽常表现为 API 延迟”、适用边界“应关联请求 Trace、EF 日志和数据库执行计划，先减少查询与数据量再盲目扩容”以及面向场景的正确取证方式，不能因为题干使用否定问法而反选这些有效结论。
0992 针对“更多请求并发进入后数据库雪崩”进行上线评审，哪项决策依据最完整？
难度： 实战
- A. 按“提高 Kestrel 并发限制能修复任何慢 SQL”修改实现，并把一次请求成功作为验收结果。
- B. 按“慢查询、过量往返、锁等待和连接池耗尽常表现为 API 延迟”修改代码后直接上线，不验证“应关联请求 Trace、EF 日志和数据库执行计划，先减少查询与数据量再盲目扩容”。
- C. 只验证“应关联请求 Trace、EF 日志和数据库执行计划，先减少查询与数据量再盲目扩容”，但实现仍继续依赖“提高 Kestrel 并发限制能修复任何慢 SQL”。
- D. 按“慢查询、过量往返、锁等待和连接池耗尽常表现为 API 延迟”修正实现，并用测试或遥测验证“应关联请求 Trace、EF 日志和数据库执行计划，先减少查询与数据量再盲目扩容”。
查看答案与解析
正确答案D
完整决策同时覆盖规则与验证：慢查询、过量往返、锁等待和连接池耗尽常表现为 API 延迟；并确认 应关联请求 Trace、EF 日志和数据库执行计划，先减少查询与数据量再盲目扩容。继续接受“提高 Kestrel 并发限制能修复任何慢 SQL”会让评审依据失真；只改代码不验证边界，或只检查边界却沿用误区，都不足以判断“更多请求并发进入后数据库雪崩”这一生产场景能否安全上线。
0993 在 负载测试 的框架契约中，哪项是应直接依赖的主规则？
难度： 基础
- A. 负载测试应模拟真实请求比例、数据规模、连接复用、预热和持续时间
- B. 单用户循环请求达到目标 RPS 就证明并发场景稳定
- C. 只看本机短时平均值不能推断生产尾延迟，需观察 p95、p99、错误和资源饱和
- D. 观察到“上线后高并发出现锁竞争和超时”即可把一次现象当成完整框架契约。
查看答案与解析
正确答案A
正确答案直接描述 负载测试 的主规则：负载测试应模拟真实请求比例、数据规模、连接复用、预热和持续时间。选项“只看本机短时平均值不能推断生产尾延迟，需观察 p95、p99、错误和资源饱和”是使用规则时要验证的边界，不是规则本身；“单用户循环请求达到目标 RPS 就证明并发场景稳定”则是会导致错误实现的典型误区。场景只能提供线索，不能替代框架契约。
0994 上线后高并发出现锁竞争和超时。排查时哪项动作最合理？
难度： 进阶
- A. 直接按“单用户循环请求达到目标 RPS 就证明并发场景稳定”定性，不再检查配置、身份或运行时证据。
- B. 只增加重试次数或机器资源，暂不核对“只看本机短时平均值不能推断生产尾延迟，需观察 p95、p99、错误和资源饱和”。
- C. 以一次成功请求作为结论，不再确认“负载测试应模拟真实请求比例、数据规模、连接复用、预热和持续时间”是否成立。
- D. 先验证“只看本机短时平均值不能推断生产尾延迟，需观察 p95、p99、错误和资源饱和”，再依据“负载测试应模拟真实请求比例、数据规模、连接复用、预热和持续时间”判断实现是否符合契约。
查看答案与解析
正确答案D
场景“上线后高并发出现锁竞争和超时”指向 负载测试，但症状本身不能证明根因。正确排查应先确认边界“只看本机短时平均值不能推断生产尾延迟，需观察 p95、p99、错误和资源饱和”，再用主规则“负载测试应模拟真实请求比例、数据规模、连接复用、预热和持续时间”解释证据。直接采用误区“单用户循环请求达到目标 RPS 就证明并发场景稳定”、只扩容或依赖一次成功都会掩盖真实配置和请求路径。
0995 关于 负载测试，以下哪项说法不成立？
难度： 实战
- A. 负载测试应模拟真实请求比例、数据规模、连接复用、预热和持续时间
- B. 只看本机短时平均值不能推断生产尾延迟，需观察 p95、p99、错误和资源饱和
- C. 单用户循环请求达到目标 RPS 就证明并发场景稳定
- D. 出现“上线后高并发出现锁竞争和超时”时，应收集证据并同时核对主规则与适用边界。
查看答案与解析
正确答案C
题目要求选出不成立的说法，答案“单用户循环请求达到目标 RPS 就证明并发场景稳定”正是 负载测试 的典型误区。其余三项分别给出了主规则“负载测试应模拟真实请求比例、数据规模、连接复用、预热和持续时间”、适用边界“只看本机短时平均值不能推断生产尾延迟，需观察 p95、p99、错误和资源饱和”以及面向场景的正确取证方式，不能因为题干使用否定问法而反选这些有效结论。
0996 针对“上线后高并发出现锁竞争和超时”进行上线评审，哪项决策依据最完整？
难度： 实战
- A. 按“单用户循环请求达到目标 RPS 就证明并发场景稳定”修改实现，并把一次请求成功作为验收结果。
- B. 按“负载测试应模拟真实请求比例、数据规模、连接复用、预热和持续时间”修正实现，并用测试或遥测验证“只看本机短时平均值不能推断生产尾延迟，需观察 p95、p99、错误和资源饱和”。
- C. 按“负载测试应模拟真实请求比例、数据规模、连接复用、预热和持续时间”修改代码后直接上线，不验证“只看本机短时平均值不能推断生产尾延迟，需观察 p95、p99、错误和资源饱和”。
- D. 只验证“只看本机短时平均值不能推断生产尾延迟，需观察 p95、p99、错误和资源饱和”，但实现仍继续依赖“单用户循环请求达到目标 RPS 就证明并发场景稳定”。
查看答案与解析
正确答案B
完整决策同时覆盖规则与验证：负载测试应模拟真实请求比例、数据规模、连接复用、预热和持续时间；并确认 只看本机短时平均值不能推断生产尾延迟，需观察 p95、p99、错误和资源饱和。继续接受“单用户循环请求达到目标 RPS 就证明并发场景稳定”会让评审依据失真；只改代码不验证边界，或只检查边界却沿用误区，都不足以判断“上线后高并发出现锁竞争和超时”这一生产场景能否安全上线。
0997 在 分层排障 的框架契约中，哪项是应直接依赖的主规则？
难度： 基础
- A. 出现 500 时先重启并提高所有超时，无需保存诊断证据
- B. 应从入口状态码和延迟开始，沿 Kestrel、管道、下游、数据库和资源指标缩小范围
- C. 一次只验证一个假设并保留时间线，避免同时改多个配置掩盖根因
- D. 观察到“故障短暂恢复但根因持续复发”即可把一次现象当成完整框架契约。
查看答案与解析
正确答案B
正确答案直接描述 分层排障 的主规则：应从入口状态码和延迟开始，沿 Kestrel、管道、下游、数据库和资源指标缩小范围。选项“一次只验证一个假设并保留时间线，避免同时改多个配置掩盖根因”是使用规则时要验证的边界，不是规则本身；“出现 500 时先重启并提高所有超时，无需保存诊断证据”则是会导致错误实现的典型误区。场景只能提供线索，不能替代框架契约。
0998 故障短暂恢复但根因持续复发。排查时哪项动作最合理？
难度： 进阶
- A. 直接按“出现 500 时先重启并提高所有超时，无需保存诊断证据”定性，不再检查配置、身份或运行时证据。
- B. 只增加重试次数或机器资源，暂不核对“一次只验证一个假设并保留时间线，避免同时改多个配置掩盖根因”。
- C. 以一次成功请求作为结论，不再确认“应从入口状态码和延迟开始，沿 Kestrel、管道、下游、数据库和资源指标缩小范围”是否成立。
- D. 先验证“一次只验证一个假设并保留时间线，避免同时改多个配置掩盖根因”，再依据“应从入口状态码和延迟开始，沿 Kestrel、管道、下游、数据库和资源指标缩小范围”判断实现是否符合契约。
查看答案与解析
正确答案D
场景“故障短暂恢复但根因持续复发”指向 分层排障，但症状本身不能证明根因。正确排查应先确认边界“一次只验证一个假设并保留时间线，避免同时改多个配置掩盖根因”，再用主规则“应从入口状态码和延迟开始，沿 Kestrel、管道、下游、数据库和资源指标缩小范围”解释证据。直接采用误区“出现 500 时先重启并提高所有超时，无需保存诊断证据”、只扩容或依赖一次成功都会掩盖真实配置和请求路径。
0999 关于 分层排障，以下哪项说法不成立？
难度： 实战
- A. 出现 500 时先重启并提高所有超时，无需保存诊断证据
- B. 应从入口状态码和延迟开始，沿 Kestrel、管道、下游、数据库和资源指标缩小范围
- C. 一次只验证一个假设并保留时间线，避免同时改多个配置掩盖根因
- D. 出现“故障短暂恢复但根因持续复发”时，应收集证据并同时核对主规则与适用边界。
查看答案与解析
正确答案A
题目要求选出不成立的说法，答案“出现 500 时先重启并提高所有超时，无需保存诊断证据”正是 分层排障 的典型误区。其余三项分别给出了主规则“应从入口状态码和延迟开始，沿 Kestrel、管道、下游、数据库和资源指标缩小范围”、适用边界“一次只验证一个假设并保留时间线，避免同时改多个配置掩盖根因”以及面向场景的正确取证方式，不能因为题干使用否定问法而反选这些有效结论。
1000 针对“故障短暂恢复但根因持续复发”进行上线评审，哪项决策依据最完整？
难度： 实战
- A. 按“出现 500 时先重启并提高所有超时，无需保存诊断证据”修改实现，并把一次请求成功作为验收结果。
- B. 按“应从入口状态码和延迟开始，沿 Kestrel、管道、下游、数据库和资源指标缩小范围”修改代码后直接上线，不验证“一次只验证一个假设并保留时间线，避免同时改多个配置掩盖根因”。
- C. 按“应从入口状态码和延迟开始，沿 Kestrel、管道、下游、数据库和资源指标缩小范围”修正实现，并用测试或遥测验证“一次只验证一个假设并保留时间线，避免同时改多个配置掩盖根因”。
- D. 只验证“一次只验证一个假设并保留时间线，避免同时改多个配置掩盖根因”，但实现仍继续依赖“出现 500 时先重启并提高所有超时，无需保存诊断证据”。
查看答案与解析
正确答案C
完整决策同时覆盖规则与验证：应从入口状态码和延迟开始，沿 Kestrel、管道、下游、数据库和资源指标缩小范围；并确认 一次只验证一个假设并保留时间线，避免同时改多个配置掩盖根因。继续接受“出现 500 时先重启并提高所有超时，无需保存诊断证据”会让评审依据失真；只改代码不验证边界，或只检查边界却沿用误区，都不足以判断“故障短暂恢复但根因持续复发”这一生产场景能否安全上线。