第2章 高频面试问题与回答框架：常见问题分类、STAR答题结构、公司侧重点分析方法

面试问题：请解释 .NET GC 的回收机制，并说明如何避免长时间挂起。

面试官考察点：GC 分代原理、工作站/服务器模式差异、低延迟场景下的配置经验。

回答框架（STAR）：

• S – 某电商订单系统压测时发现 GC 暂停高达 200ms，导致接口超时。
• T – 将 GC 暂停控制在 50ms 以内，同时保持吞吐。
• A – 启用 Server GC + 调整 GCLatencyMode.SustainedLowLatency，并拆分大对象分配。
• R – 暂停降至 30ms，TP99 降低 40%。

简短示例回答（80字）：
在订单系统压测中，GC 暂停 200ms 导致超时。我分析是第 2 代回收频率过高，通过切换 Server GC + 设置延迟模式为 SustainedLowLatency，并拆分 85KB 以上的大对象分配，最终暂停降到 30ms，接口 TP99 从 1.2s 降至 0.7s。

可能追问：

• Server GC 和工作站 GC 在内部实现上有何不同？
• 如果使用 GCLatencyMode.SustainedLowLatency 导致内存上涨如何处理？

面试问题：线上某接口响应慢（从 20ms 涨到 500ms），你如何排查？

面试官考察点：问题定位流程、工具链熟练度、性能思维（IO/CPU/锁）。

回答框架（STAR）：

• S – 用户反馈下单接口响应从 20ms 飙升至 500ms，CPU 未满载。
• T – 迅速定位根因并恢复 SLA。
• A – 先查看 SkyWalking 发现 Redis 调用耗时 400ms；用 StackExchange.Redis 的 TimeoutException 日志确认是连接池耗尽；排查发现某事故导致 Redis 集群主从切换，连接未重建。
• R – 重启连接池并增加健康检查后接口恢复 25ms，事后添加自动重连机制。

简短示例回答（90字）：
接到告警后我立即查看链路追踪，发现 Redis 调用耗时 400ms。用 Redis 连接池日志确认是连接池耗尽，原因是当天 Redis 主从切换导致旧连接失效。我通过重启连接池并增加 ConnectionMultiplexer.ConnectAsync 重试逻辑，接口恢复 25ms，并推动添加健康检查定时任务。

可能追问：

• 连接池耗尽时为什么不自动重建？你是怎么确认的？
• 如果 Redis 本身性能没问题，你会怎么进一步排查？

面试问题：你们团队是如何做性能监控与持续优化的？

面试官考察点：监控体系成熟度、自动化能力、量化优化习惯。

回答框架（STAR）：

• S – 原有监控只有告警无趋势分析，上线后性能退化难以发现。
• T – 建立“指标→基线→自动比对”的持续监控流程。
• A – 引入 Prometheus + Grafana 采集 .NET 进程级指标（CPU/GC/线程池），每版本发布后自动对比基线，触发阈值自动创建 Jira。
• R – 性能退化发现时间从 2 天缩短到 30 分钟，优化效率提升 3 倍。

简短示例回答（80字）：
我们之前只有基础告警，无法发现缓慢退化。我主导搭建了 Prometheus + Grafana 监控，采集 GC 暂停、线程池队列数等指标，并设定基线。每个版本上线后自动对比，超出 10% 自动提单。结果一次 GC 内存泄露在 30 分钟就被发现，避免了线上事故。

可能追问：

• 你选的哪些性能指标作为基线？为什么？
• 如何处理监控本身的性能开销？