如何排查线上环境CPU飙高和OOM

# 线上危机时刻：如何快速排查 CPU 飙高与 OOM

在生产环境中，服务突然卡顿、响应超时甚至直接崩溃，是每一位后端开发和运维工程师最不愿面对的场景。其中，“CPU 飙高”和“OOM（内存溢出）”是最常见的两类故障，它们往往在深夜或流量高峰时突然爆发，若缺乏系统的排查思路，极易陷入盲目重启的误区。本课程《如何排查线上环境 CPU 飙高和 OOM》旨在帮助开发者建立一套标准化、高效率的线上故障定位方法论，从现象观察到底层原理，再到工具实操，逐一击破这两大经典难题。

一、 CPU 飙高：让进程“冷静”下来

CPU 使用率瞬间飙升至 100%，通常意味着某个进程陷入了死循环、频繁进行上下文切换，或是触发了频繁的 GC 回收。

课程首先强调**定位瓶颈线程**。当发现 CPU 负载异常时，第一步应利用 `top` 命令锁定占用资源最高的进程 PID，随后通过 `top -Hp <PID>` 查看该进程下的线程状态。关键在于将线程 ID 转换为十六进制格式，再结合 `jstack <PID>` 生成的堆栈信息，精准定位到具体是哪一行代码、哪个方法在执行。

其次，深入分析**热点代码特征**。如果是业务逻辑导致的 CPU 高，通常表现为某个线程始终处于 RUNNABLE 状态；若是 Java 应用，则需警惕全量 GC（Full GC）频繁触发，此时 CPU 大部分时间被垃圾回收器占用，而非执行业务代码。课程将详细演示如何通过分析堆栈中的锁竞争、正则表达式回溯或无限循环代码来修复问题。

二、 OOM 排查：寻找内存中的“隐形大象”

OOM 故障的本质是内存资源耗尽，导致 JVM 无法为对象分配空间。排查 OOM 的核心在于**复现现场**与**还原真相**。

课程介绍了两种主流路径：一是**在线排查**，即在内存不足前通过监控预警发现趋势，利用 `jmap` 导出堆转储快照（Heap Dump），配合 MAT 或 JProfiler 等工具分析内存泄露点；二是**事后分析**，针对已崩溃的服务，检查是否配置了 `-XX:+HeapDumpOnOutOfMemoryError` 参数，以便在 OOM 发生时自动保存现场。

重点内容聚焦于**内存泄漏的类型识别**。课程将通过实例展示常见泄漏场景：如静态集合类无限增长、未关闭的资源流、监听器未注销以及线程局部变量（ThreadLocal）误用等。通过可视化分析引用链，工程师可以快速定位持有大量对象的大对象或集合，从而从根本上优化内存模型。

三、 总结与建议

排查线上故障不仅是技术能力的体现，更是工程素养的锤炼。本课程不仅提供命令级的操作指南，更强调建立“监控先行、日志辅助、证据留存”的预防机制。通过系统学习，你将掌握在高压环境下保持冷静、快速定位根因的能力，确保线上服务的稳定性与高可用性。