面试官，如果遇到这种情况，我会立即按照以下步骤操作，目标是尽快恢复服务，而不是立即深入排查复杂原因。

扩容/重启：这是最快、最有效的止损方案。
- 水平扩容：如果云环境，立即申请新的服务器实例，加入集群，将流量切到新节点。这是首选，对用户影响最小。
- 重启大法：如果无法快速扩容，果断选择分批重启应用服务器。先重启一小部分（如20%），验证服务恢复后，再逐步重启其他节点。重启可以立即释放资源，清除可能的内存泄漏或死循环等问题。
服务降级/限流：
- 降级：立即确认是否有非核心功能（如排行榜、推荐系统、报表生成）可以紧急降级，直接关闭其服务以节省CPU资源。
- 限流/熔断：在网关或API层立即配置严格限流，拒绝大部分非关键请求，只保障核心业务（如下单、支付）的少量请求能通过，防止整个系统被拖垮。

在重启/扩容的同时，必须立刻抓取现场信息，以便后续分析，避免问题复发。

快速登录服务器，使用标准命令行工具链定位问题进程和线程：
- top -c：查看整体CPU使用情况，找到最耗CPU的进程ID（PID）。
- top -Hp [PID]：查看该进程中最耗CPU的线程ID（TID）。
- printf "%x\n" [TID]：将TID转换为十六进制，便于在日志中搜索。
抓取线程快照（Thread Dump/JStack）：
- jstack [PID] > jstack.log：立即抓取Java应用的线程栈信息。
- 重点分析之前找到的高CPU线程的十六进制ID，查看它正在执行什么代码（通常是处于RUNNABLE状态，卡在某个方法循环、计算或IO等待）。
辅助信息收集：
- vmstat 1 / mpstat 1：查看CPU使用分布（用户态、内核态、IO等待）。
- jstat -gcutil [PID] 1s：查看GC情况，判断是否因频繁FULL GC导致。
- 查看监控系统：如Prometheus/Grafana，观察问题发生时间点的QPS、响应时间、缓存命中率、数据库连接数等指标的变化，寻找关联性。

根据第二步收集的信息，常见原因和应对策略如下：

可能原因	分析线索	解决方案
1. 死循环/无限递归	Thread Dump中某线程长期`RUNNABLE`且执行相同方法。	修复代码逻辑，增加循环边界或终止条件。
2. 频繁GC（特别是FULL GC）	`jstat`显示老年代几乎占满，GC时间飙升。	紧急重启；长期需分析内存泄漏、优化JVM参数。
3. 序列化/反序列化问题	线程栈出现在`ObjectInputStream`等相关方法。	回滚相关代码或检查输入数据是否异常。
4. 锁竞争激烈	线程栈中出现大量`BLOCKED`状态的线程，等待同一锁。	优化锁粒度、改用并发类、避免长时间持锁。
5. 算法复杂度爆炸	因某个特定请求，触发了高复杂度（如O(n²)）的计算。	限流、优化算法、增加缓存。
6. 外部依赖变慢	线程栈大量卡在数据库/网络IO调用，监控显示依赖方超时。	快速熔断该依赖， fallback降级，避免被拖垮。

复盘：事后必须组织复盘，写出事故报告（Post-mortem），明确根本原因、处理过程、改进措施。
建设监控告警：
- 设置CPU使用率、GC频率、接口响应时间、错误率等阈值告警，做到提前发现，而非事后补救。
常态化措施：
- 压测：定期进行压力测试，了解系统瓶颈和容量上限。
- 限流降级：在代码和架构中预先埋好降级开关和限流策略。
- 可观测性：完善链路追踪（APM）、日志系统，保证下次能更快定位问题。