- 线上业务反馈某台核心应用服务器在凌晨 2:00-3:00 出现间歇性响应超时，CPU 使用率峰值达到 95% 以上，持续时间约 5-8 分钟，连续三晚均有发生。本文记录整个排查过程和最终定位思路。
排查步骤:
1. 确认现象
- 登录目标服务器，先用 top 和 htop 查看当前资源使用情况，确认问题时段确实存在 CPU 飙升。由于问题是间歇性的，需要保留历史数据：
2. 定位可疑进程
通过 ps aux --sort=-%cpu | head -20 抓取 CPU 占用 TOP 进程，发现在问题时段有一个 Java 进程（应用服务）CPU 飙高。进一步用 top -H -p <pid> 查看该进程内线程的 CPU 分布，定位到具体线程 ID。
3. 分析 JVM 线程栈
- 用 jstack 导出线程快照，对照高 CPU 线程的十六进制 ID 找到对应线程栈：
- 分析发现该线程一直在执行 Full GC，说明堆内存不足或存在内存泄漏。
4. 查看 JVM 内存与 GC 日志
确认老年代持续增长，在问题时段触发频繁 Full GC，导致 STW（Stop The World）停顿，进而造成接口超时。
5. 分析堆转储
用 MAT（Memory Analyzer Tool）分析 heap.bin，发现一个定时任务在凌晨批量加载大量数据到内存中做计算，数据量超出预期，触发了内存瓶颈。
6. 根因与修复
- 根因是定时任务分页查询失效，本应每次取 1000 条，实际由于 SQL 条件拼接错误导致全表扫描加载了 200W+ 条数据到内存。
- 修复措施：
