ASP.NET Core 生产实践试题 06：ThreadPool 饥饿与同步阻塞
101 关于sync-over-async，哪一项准确描述了应依赖的平台契约？
难度： 基础
- A. ASP.NET Core 没有 SynchronizationContext，所以同步等待完全安全
- B. 在请求路径用 Result、Wait 或 GetResult 同步等待异步操作会占用线程并可能引发线程池饥饿
- C. ASP.NET Core 通常无传统同步上下文，但没有死锁不等于没有吞吐风险
- D. 只要观察到“低 CPU 下请求延迟持续升高”，就能把这次现象视为所有环境中的固定行为。
查看答案与解析
正确答案B
正确项给出了sync-over-async可直接依赖的规则：“在请求路径用 Result、Wait 或 GetResult 同步等待异步操作会占用线程并可能引发线程池饥饿”。“ASP.NET Core 通常无传统同步上下文，但没有死锁不等于没有吞吐风险”是应用规则前必须确认的边界，不是规则本身；“ASP.NET Core 没有 SynchronizationContext，所以同步等待完全安全”则把常见现象或实现细节扩大成了平台保证。场景“低 CPU 下请求延迟持续升高”只能作为排查线索，仍需结合目标框架、发布方式和运行时证据验证。
102 生产环境出现“低 CPU 下请求延迟持续升高”时，针对sync-over-async应如何排查？
难度： 进阶
- A. 直接采用“ASP.NET Core 没有 SynchronizationContext，所以同步等待完全安全”解释现象，不再收集目标进程和发布配置证据。
- B. 只增加机器资源或重启进程，以一次恢复结果代替对“ASP.NET Core 通常无传统同步上下文，但没有死锁不等于没有吞吐风险”的验证。
- C. 先验证“ASP.NET Core 通常无传统同步上下文，但没有死锁不等于没有吞吐风险”，再使用运行时指标、日志或最小复现检查“在请求路径用 Result、Wait 或 GetResult 同步等待异步操作会占用线程并可能引发线程池饥饿”是否成立。
- D. 只检查代码是否能够编译，通过后便认定“在请求路径用 Result、Wait 或 GetResult 同步等待异步操作会占用线程并可能引发线程池饥饿”在当前部署中必然成立。
查看答案与解析
正确答案C
“低 CPU 下请求延迟持续升高”可能由多条路径造成，不能直接证明根因。合理顺序是先确认边界“ASP.NET Core 通常无传统同步上下文，但没有死锁不等于没有吞吐风险”，再以“在请求路径用 Result、Wait 或 GetResult 同步等待异步操作会占用线程并可能引发线程池饥饿”组织证据。采用误区“ASP.NET Core 没有 SynchronizationContext，所以同步等待完全安全”、盲目扩容或只看编译结果，都跳过了运行配置与真实调用路径，无法形成可复核的诊断结论。
103 评审sync-over-async相关实现时，以下哪项判断不成立？
难度： 实战
- A. 在请求路径用 Result、Wait 或 GetResult 同步等待异步操作会占用线程并可能引发线程池饥饿
- B. ASP.NET Core 通常无传统同步上下文，但没有死锁不等于没有吞吐风险
- C. 遇到“低 CPU 下请求延迟持续升高”时，应把可观察证据与平台契约分开记录，再验证二者是否一致。
- D. ASP.NET Core 没有 SynchronizationContext，所以同步等待完全安全
查看答案与解析
正确答案D
题目要求找出不成立的判断，“ASP.NET Core 没有 SynchronizationContext，所以同步等待完全安全”正是sync-over-async的典型误区。主规则“在请求路径用 Result、Wait 或 GetResult 同步等待异步操作会占用线程并可能引发线程池饥饿”描述了实现应依赖的契约，边界“ASP.NET Core 通常无传统同步上下文，但没有死锁不等于没有吞吐风险”限制了结论的适用范围。生产场景还需要保留指标、日志、跟踪或转储等证据，不能因为一次成功或失败就反转稳定契约。
104 准备上线涉及sync-over-async的改动时，哪项验收方案最完整？
难度： 实战
- A. 依据“在请求路径用 Result、Wait 或 GetResult 同步等待异步操作会占用线程并可能引发线程池饥饿”实现，在“ASP.NET Core 通常无传统同步上下文，但没有死锁不等于没有吞吐风险”成立的环境中验证，并为“低 CPU 下请求延迟持续升高”保留可观测证据和回退条件。
- B. 依据“ASP.NET Core 没有 SynchronizationContext，所以同步等待完全安全”完成修改，只要本地运行一次成功就立即发布。
- C. 按照“在请求路径用 Result、Wait 或 GetResult 同步等待异步操作会占用线程并可能引发线程池饥饿”修改代码，但不核对“ASP.NET Core 通常无传统同步上下文，但没有死锁不等于没有吞吐风险”或目标发布模式。
- D. 只验证“ASP.NET Core 通常无传统同步上下文，但没有死锁不等于没有吞吐风险”，实现仍继续依赖“ASP.NET Core 没有 SynchronizationContext，所以同步等待完全安全”这一未经证明的假设。
查看答案与解析
正确答案A
完整验收必须同时覆盖规则、边界和生产证据：实现遵守“在请求路径用 Result、Wait 或 GetResult 同步等待异步操作会占用线程并可能引发线程池饥饿”，部署环境满足“ASP.NET Core 通常无传统同步上下文，但没有死锁不等于没有吞吐风险”，并能在“低 CPU 下请求延迟持续升高”出现时定位和回退。其余方案分别依赖错误假设、遗漏环境验证或只检查边界却保留错误实现，均不能证明改动在生产环境中安全。
105 关于阻塞检测，哪一项准确描述了应依赖的平台契约？
难度： 基础
- A. CPU 未满即可排除线程池饥饿
- B. 必须结合 trace 或 dump 查看阻塞栈，单一线程数不能直接定根因
- C. 线程池线程数快速增长、队列积压和完成率下降是饥饿的重要组合信号
- D. 只要观察到“大量线程停在 Task.Wait”，就能把这次现象视为所有环境中的固定行为。
查看答案与解析
正确答案C
正确项给出了阻塞检测可直接依赖的规则：“线程池线程数快速增长、队列积压和完成率下降是饥饿的重要组合信号”。“必须结合 trace 或 dump 查看阻塞栈，单一线程数不能直接定根因”是应用规则前必须确认的边界，不是规则本身；“CPU 未满即可排除线程池饥饿”则把常见现象或实现细节扩大成了平台保证。场景“大量线程停在 Task.Wait”只能作为排查线索，仍需结合目标框架、发布方式和运行时证据验证。
106 生产环境出现“大量线程停在 Task.Wait”时，针对阻塞检测应如何排查？
难度： 进阶
- A. 直接采用“CPU 未满即可排除线程池饥饿”解释现象，不再收集目标进程和发布配置证据。
- B. 只增加机器资源或重启进程，以一次恢复结果代替对“必须结合 trace 或 dump 查看阻塞栈，单一线程数不能直接定根因”的验证。
- C. 只检查代码是否能够编译，通过后便认定“线程池线程数快速增长、队列积压和完成率下降是饥饿的重要组合信号”在当前部署中必然成立。
- D. 先验证“必须结合 trace 或 dump 查看阻塞栈，单一线程数不能直接定根因”，再使用运行时指标、日志或最小复现检查“线程池线程数快速增长、队列积压和完成率下降是饥饿的重要组合信号”是否成立。
查看答案与解析
正确答案D
“大量线程停在 Task.Wait”可能由多条路径造成，不能直接证明根因。合理顺序是先确认边界“必须结合 trace 或 dump 查看阻塞栈，单一线程数不能直接定根因”，再以“线程池线程数快速增长、队列积压和完成率下降是饥饿的重要组合信号”组织证据。采用误区“CPU 未满即可排除线程池饥饿”、盲目扩容或只看编译结果，都跳过了运行配置与真实调用路径，无法形成可复核的诊断结论。
107 评审阻塞检测相关实现时，以下哪项判断不成立？
难度： 实战
- A. CPU 未满即可排除线程池饥饿
- B. 线程池线程数快速增长、队列积压和完成率下降是饥饿的重要组合信号
- C. 必须结合 trace 或 dump 查看阻塞栈，单一线程数不能直接定根因
- D. 遇到“大量线程停在 Task.Wait”时，应把可观察证据与平台契约分开记录，再验证二者是否一致。
查看答案与解析
正确答案A
题目要求找出不成立的判断，“CPU 未满即可排除线程池饥饿”正是阻塞检测的典型误区。主规则“线程池线程数快速增长、队列积压和完成率下降是饥饿的重要组合信号”描述了实现应依赖的契约，边界“必须结合 trace 或 dump 查看阻塞栈，单一线程数不能直接定根因”限制了结论的适用范围。生产场景还需要保留指标、日志、跟踪或转储等证据，不能因为一次成功或失败就反转稳定契约。
108 准备上线涉及阻塞检测的改动时，哪项验收方案最完整？
难度： 实战
- A. 依据“CPU 未满即可排除线程池饥饿”完成修改，只要本地运行一次成功就立即发布。
- B. 依据“线程池线程数快速增长、队列积压和完成率下降是饥饿的重要组合信号”实现，在“必须结合 trace 或 dump 查看阻塞栈，单一线程数不能直接定根因”成立的环境中验证，并为“大量线程停在 Task.Wait”保留可观测证据和回退条件。
- C. 按照“线程池线程数快速增长、队列积压和完成率下降是饥饿的重要组合信号”修改代码，但不核对“必须结合 trace 或 dump 查看阻塞栈，单一线程数不能直接定根因”或目标发布模式。
- D. 只验证“必须结合 trace 或 dump 查看阻塞栈，单一线程数不能直接定根因”，实现仍继续依赖“CPU 未满即可排除线程池饥饿”这一未经证明的假设。
查看答案与解析
正确答案B
完整验收必须同时覆盖规则、边界和生产证据：实现遵守“线程池线程数快速增长、队列积压和完成率下降是饥饿的重要组合信号”，部署环境满足“必须结合 trace 或 dump 查看阻塞栈，单一线程数不能直接定根因”，并能在“大量线程停在 Task.Wait”出现时定位和回退。其余方案分别依赖错误假设、遗漏环境验证或只检查边界却保留错误实现，均不能证明改动在生产环境中安全。
109 关于Task.Run 包装，哪一项准确描述了应依赖的平台契约？
难度： 基础
- A. 所有同步数据库调用都可用 Task.Run 转换为可扩展异步 I/O
- B. 少量受控 CPU 工作与不可替换同步库需要分别评估和限流
- C. 只要观察到“并发升高后 Task.Run 队列堆积”，就能把这次现象视为所有环境中的固定行为。
- D. 把同步 I/O 包进 Task.Run 只是把阻塞移到线程池，不能提高服务器可用线程总量
查看答案与解析
正确答案D
正确项给出了Task.Run 包装可直接依赖的规则：“把同步 I/O 包进 Task.Run 只是把阻塞移到线程池，不能提高服务器可用线程总量”。“少量受控 CPU 工作与不可替换同步库需要分别评估和限流”是应用规则前必须确认的边界，不是规则本身；“所有同步数据库调用都可用 Task.Run 转换为可扩展异步 I/O”则把常见现象或实现细节扩大成了平台保证。场景“并发升高后 Task.Run 队列堆积”只能作为排查线索，仍需结合目标框架、发布方式和运行时证据验证。
110 生产环境出现“并发升高后 Task.Run 队列堆积”时，针对Task.Run 包装应如何排查？
难度： 进阶
- A. 直接采用“所有同步数据库调用都可用 Task.Run 转换为可扩展异步 I/O”解释现象，不再收集目标进程和发布配置证据。
- B. 只增加机器资源或重启进程，以一次恢复结果代替对“少量受控 CPU 工作与不可替换同步库需要分别评估和限流”的验证。
- C. 先验证“少量受控 CPU 工作与不可替换同步库需要分别评估和限流”，再使用运行时指标、日志或最小复现检查“把同步 I/O 包进 Task.Run 只是把阻塞移到线程池，不能提高服务器可用线程总量”是否成立。
- D. 只检查代码是否能够编译，通过后便认定“把同步 I/O 包进 Task.Run 只是把阻塞移到线程池，不能提高服务器可用线程总量”在当前部署中必然成立。
查看答案与解析
正确答案C
“并发升高后 Task.Run 队列堆积”可能由多条路径造成，不能直接证明根因。合理顺序是先确认边界“少量受控 CPU 工作与不可替换同步库需要分别评估和限流”，再以“把同步 I/O 包进 Task.Run 只是把阻塞移到线程池，不能提高服务器可用线程总量”组织证据。采用误区“所有同步数据库调用都可用 Task.Run 转换为可扩展异步 I/O”、盲目扩容或只看编译结果，都跳过了运行配置与真实调用路径，无法形成可复核的诊断结论。
111 评审Task.Run 包装相关实现时，以下哪项判断不成立？
难度： 实战
- A. 把同步 I/O 包进 Task.Run 只是把阻塞移到线程池，不能提高服务器可用线程总量
- B. 所有同步数据库调用都可用 Task.Run 转换为可扩展异步 I/O
- C. 少量受控 CPU 工作与不可替换同步库需要分别评估和限流
- D. 遇到“并发升高后 Task.Run 队列堆积”时，应把可观察证据与平台契约分开记录，再验证二者是否一致。
查看答案与解析
正确答案B
题目要求找出不成立的判断，“所有同步数据库调用都可用 Task.Run 转换为可扩展异步 I/O”正是Task.Run 包装的典型误区。主规则“把同步 I/O 包进 Task.Run 只是把阻塞移到线程池，不能提高服务器可用线程总量”描述了实现应依赖的契约，边界“少量受控 CPU 工作与不可替换同步库需要分别评估和限流”限制了结论的适用范围。生产场景还需要保留指标、日志、跟踪或转储等证据，不能因为一次成功或失败就反转稳定契约。
112 准备上线涉及Task.Run 包装的改动时，哪项验收方案最完整？
难度： 实战
- A. 依据“把同步 I/O 包进 Task.Run 只是把阻塞移到线程池，不能提高服务器可用线程总量”实现，在“少量受控 CPU 工作与不可替换同步库需要分别评估和限流”成立的环境中验证，并为“并发升高后 Task.Run 队列堆积”保留可观测证据和回退条件。
- B. 依据“所有同步数据库调用都可用 Task.Run 转换为可扩展异步 I/O”完成修改，只要本地运行一次成功就立即发布。
- C. 按照“把同步 I/O 包进 Task.Run 只是把阻塞移到线程池，不能提高服务器可用线程总量”修改代码，但不核对“少量受控 CPU 工作与不可替换同步库需要分别评估和限流”或目标发布模式。
- D. 只验证“少量受控 CPU 工作与不可替换同步库需要分别评估和限流”，实现仍继续依赖“所有同步数据库调用都可用 Task.Run 转换为可扩展异步 I/O”这一未经证明的假设。
查看答案与解析
正确答案A
完整验收必须同时覆盖规则、边界和生产证据：实现遵守“把同步 I/O 包进 Task.Run 只是把阻塞移到线程池，不能提高服务器可用线程总量”，部署环境满足“少量受控 CPU 工作与不可替换同步库需要分别评估和限流”，并能在“并发升高后 Task.Run 队列堆积”出现时定位和回退。其余方案分别依赖错误假设、遗漏环境验证或只检查边界却保留错误实现，均不能证明改动在生产环境中安全。
113 关于热路径分配，哪一项准确描述了应依赖的平台契约？
难度： 基础
- A. 只要改用 struct 就能消除所有请求分配
- B. 请求热路径的大对象分配和频繁高代 GC 会增加停顿并降低有效吞吐
- C. 优化前应通过分配率、GC 暂停和调用栈确认来源
- D. 只要观察到“延迟尖峰与 Gen 2 GC 同时出现”，就能把这次现象视为所有环境中的固定行为。
查看答案与解析
正确答案B
正确项给出了热路径分配可直接依赖的规则：“请求热路径的大对象分配和频繁高代 GC 会增加停顿并降低有效吞吐”。“优化前应通过分配率、GC 暂停和调用栈确认来源”是应用规则前必须确认的边界，不是规则本身；“只要改用 struct 就能消除所有请求分配”则把常见现象或实现细节扩大成了平台保证。场景“延迟尖峰与 Gen 2 GC 同时出现”只能作为排查线索，仍需结合目标框架、发布方式和运行时证据验证。
114 生产环境出现“延迟尖峰与 Gen 2 GC 同时出现”时，针对热路径分配应如何排查？
难度： 进阶
- A. 先验证“优化前应通过分配率、GC 暂停和调用栈确认来源”，再使用运行时指标、日志或最小复现检查“请求热路径的大对象分配和频繁高代 GC 会增加停顿并降低有效吞吐”是否成立。
- B. 直接采用“只要改用 struct 就能消除所有请求分配”解释现象，不再收集目标进程和发布配置证据。
- C. 只增加机器资源或重启进程，以一次恢复结果代替对“优化前应通过分配率、GC 暂停和调用栈确认来源”的验证。
- D. 只检查代码是否能够编译，通过后便认定“请求热路径的大对象分配和频繁高代 GC 会增加停顿并降低有效吞吐”在当前部署中必然成立。
查看答案与解析
正确答案A
“延迟尖峰与 Gen 2 GC 同时出现”可能由多条路径造成，不能直接证明根因。合理顺序是先确认边界“优化前应通过分配率、GC 暂停和调用栈确认来源”，再以“请求热路径的大对象分配和频繁高代 GC 会增加停顿并降低有效吞吐”组织证据。采用误区“只要改用 struct 就能消除所有请求分配”、盲目扩容或只看编译结果，都跳过了运行配置与真实调用路径，无法形成可复核的诊断结论。
115 评审热路径分配相关实现时，以下哪项判断不成立？
难度： 实战
- A. 请求热路径的大对象分配和频繁高代 GC 会增加停顿并降低有效吞吐
- B. 优化前应通过分配率、GC 暂停和调用栈确认来源
- C. 只要改用 struct 就能消除所有请求分配
- D. 遇到“延迟尖峰与 Gen 2 GC 同时出现”时，应把可观察证据与平台契约分开记录，再验证二者是否一致。
查看答案与解析
正确答案C
题目要求找出不成立的判断，“只要改用 struct 就能消除所有请求分配”正是热路径分配的典型误区。主规则“请求热路径的大对象分配和频繁高代 GC 会增加停顿并降低有效吞吐”描述了实现应依赖的契约，边界“优化前应通过分配率、GC 暂停和调用栈确认来源”限制了结论的适用范围。生产场景还需要保留指标、日志、跟踪或转储等证据，不能因为一次成功或失败就反转稳定契约。
116 准备上线涉及热路径分配的改动时，哪项验收方案最完整？
难度： 实战
- A. 依据“只要改用 struct 就能消除所有请求分配”完成修改，只要本地运行一次成功就立即发布。
- B. 按照“请求热路径的大对象分配和频繁高代 GC 会增加停顿并降低有效吞吐”修改代码，但不核对“优化前应通过分配率、GC 暂停和调用栈确认来源”或目标发布模式。
- C. 只验证“优化前应通过分配率、GC 暂停和调用栈确认来源”，实现仍继续依赖“只要改用 struct 就能消除所有请求分配”这一未经证明的假设。
- D. 依据“请求热路径的大对象分配和频繁高代 GC 会增加停顿并降低有效吞吐”实现，在“优化前应通过分配率、GC 暂停和调用栈确认来源”成立的环境中验证，并为“延迟尖峰与 Gen 2 GC 同时出现”保留可观测证据和回退条件。
查看答案与解析
正确答案D
完整验收必须同时覆盖规则、边界和生产证据：实现遵守“请求热路径的大对象分配和频繁高代 GC 会增加停顿并降低有效吞吐”，部署环境满足“优化前应通过分配率、GC 暂停和调用栈确认来源”，并能在“延迟尖峰与 Gen 2 GC 同时出现”出现时定位和回退。其余方案分别依赖错误假设、遗漏环境验证或只检查边界却保留错误实现，均不能证明改动在生产环境中安全。
117 关于异步全链路，哪一项准确描述了应依赖的平台契约？
难度： 基础
- A. Controller 方法标记 async 后所有下游调用都会自动变异步
- B. 链路中一个同步瓶颈仍可能限制整体吞吐
- C. 可扩展异步要求从入口到数据库和网络客户端都使用真正异步 API，并传播取消
- D. 只要观察到“端点是 async 但内部调用同步 SDK”，就能把这次现象视为所有环境中的固定行为。
查看答案与解析
正确答案C
正确项给出了异步全链路可直接依赖的规则：“可扩展异步要求从入口到数据库和网络客户端都使用真正异步 API，并传播取消”。“链路中一个同步瓶颈仍可能限制整体吞吐”是应用规则前必须确认的边界，不是规则本身；“Controller 方法标记 async 后所有下游调用都会自动变异步”则把常见现象或实现细节扩大成了平台保证。场景“端点是 async 但内部调用同步 SDK”只能作为排查线索，仍需结合目标框架、发布方式和运行时证据验证。
118 生产环境出现“端点是 async 但内部调用同步 SDK”时，针对异步全链路应如何排查？
难度： 进阶
- A. 先验证“链路中一个同步瓶颈仍可能限制整体吞吐”，再使用运行时指标、日志或最小复现检查“可扩展异步要求从入口到数据库和网络客户端都使用真正异步 API，并传播取消”是否成立。
- B. 直接采用“Controller 方法标记 async 后所有下游调用都会自动变异步”解释现象，不再收集目标进程和发布配置证据。
- C. 只增加机器资源或重启进程，以一次恢复结果代替对“链路中一个同步瓶颈仍可能限制整体吞吐”的验证。
- D. 只检查代码是否能够编译，通过后便认定“可扩展异步要求从入口到数据库和网络客户端都使用真正异步 API，并传播取消”在当前部署中必然成立。
查看答案与解析
正确答案A
“端点是 async 但内部调用同步 SDK”可能由多条路径造成，不能直接证明根因。合理顺序是先确认边界“链路中一个同步瓶颈仍可能限制整体吞吐”，再以“可扩展异步要求从入口到数据库和网络客户端都使用真正异步 API，并传播取消”组织证据。采用误区“Controller 方法标记 async 后所有下游调用都会自动变异步”、盲目扩容或只看编译结果，都跳过了运行配置与真实调用路径，无法形成可复核的诊断结论。
119 评审异步全链路相关实现时，以下哪项判断不成立？
难度： 实战
- A. 可扩展异步要求从入口到数据库和网络客户端都使用真正异步 API，并传播取消
- B. 链路中一个同步瓶颈仍可能限制整体吞吐
- C. 遇到“端点是 async 但内部调用同步 SDK”时，应把可观察证据与平台契约分开记录，再验证二者是否一致。
- D. Controller 方法标记 async 后所有下游调用都会自动变异步
查看答案与解析
正确答案D
题目要求找出不成立的判断，“Controller 方法标记 async 后所有下游调用都会自动变异步”正是异步全链路的典型误区。主规则“可扩展异步要求从入口到数据库和网络客户端都使用真正异步 API，并传播取消”描述了实现应依赖的契约，边界“链路中一个同步瓶颈仍可能限制整体吞吐”限制了结论的适用范围。生产场景还需要保留指标、日志、跟踪或转储等证据，不能因为一次成功或失败就反转稳定契约。
120 准备上线涉及异步全链路的改动时，哪项验收方案最完整？
难度： 实战
- A. 依据“Controller 方法标记 async 后所有下游调用都会自动变异步”完成修改，只要本地运行一次成功就立即发布。
- B. 依据“可扩展异步要求从入口到数据库和网络客户端都使用真正异步 API，并传播取消”实现，在“链路中一个同步瓶颈仍可能限制整体吞吐”成立的环境中验证，并为“端点是 async 但内部调用同步 SDK”保留可观测证据和回退条件。
- C. 按照“可扩展异步要求从入口到数据库和网络客户端都使用真正异步 API，并传播取消”修改代码，但不核对“链路中一个同步瓶颈仍可能限制整体吞吐”或目标发布模式。
- D. 只验证“链路中一个同步瓶颈仍可能限制整体吞吐”，实现仍继续依赖“Controller 方法标记 async 后所有下游调用都会自动变异步”这一未经证明的假设。
查看答案与解析
正确答案B
完整验收必须同时覆盖规则、边界和生产证据：实现遵守“可扩展异步要求从入口到数据库和网络客户端都使用真正异步 API，并传播取消”，部署环境满足“链路中一个同步瓶颈仍可能限制整体吞吐”，并能在“端点是 async 但内部调用同步 SDK”出现时定位和回退。其余方案分别依赖错误假设、遗漏环境验证或只检查边界却保留错误实现，均不能证明改动在生产环境中安全。