应用运行时排障专题

应用运行时排障入口先按 CPU、GC、线程池和接口 RT 这几类高频现象切入，再回到 Java 和 JVM 原理层做根因收敛，会比直接扫零散命令更高效。

起步入口3 组

专题序列3 个

关联文章14 篇

起步入口先选入口

起步入口先查 CPU 和整体负载异常适合机器负载升高、线程数异常或服务整体变慢时先进入。

• CPU 飙升时怎么排查
• Java 专题

起步入口先查 GC 和内存波动适合已经看到 GC 异常频繁、堆内存抖动或停顿明显时优先进入。

• Full GC 频繁时怎么排查
• GC 日志怎么看

起步入口先查线程池与接口卡顿适合请求堆积、线程阻塞、RT 变高但现象还没完全定位时进入。

• 线程池打满时怎么排查
• 接口 RT 飙升但 CPU 不高时怎么排查

阅读路径按场景进入

入门打底先建立应用层排障顺序适合先把 CPU、GC、线程池和接口时延这几类高频现象的排查顺序理出来。

• CPU 飙升时怎么排查
• Full GC 频繁时怎么排查
• 线程池打满时怎么排查

核心原理把 JVM、线程池和请求链路联系起来适合理解为什么一个表面上的 RT 抖动，背后可能同时牵扯 GC、锁竞争和线程资源耗尽。

• GC 日志怎么看
• Java 进程排查与 Heap Dump 使用记录
• 线程池参数怎么配

工程实战围绕真实应用异常做根因收敛适合线上已经有明显现象，需要先止血、再定位、最后回到对应专题补根因的人。

• 接口 RT 飙升但 CPU 不高时怎么排查
• Java 专题
• 生产问题

案例排障从运行时故障继续扩到基础设施问题适合先从应用层切入，随后发现问题已经蔓延到数据库、网关或机器资源层的人。

• 数据与基础设施排障专题
• MySQL 连接数打满时怎么排查
• Nginx 502 怎么排查

专题序列应用运行时排障专题本专题共 3 个序列 / 14 篇文章扩容后的文章会继续按序列归档在这里，适合先选一条主线再往下读。

4 篇文章应用运行时异常排查适合把 CPU、Full GC、线程池和接口超时这类应用层异常放在一组里看。起步文章：CPU 飙升时怎么排查

• CPU 飙升时怎么排查
• Full GC 频繁时怎么排查
• 线程池打满时怎么排查

4 篇文章应用运行时典型故障案例适合把 Redis 热点、Kafka 积压、ES 慢查询和 ClickHouse 超时放在一条排障线上看。起步文章：Redis 热 Key 突增时怎么止血和回查

• Redis 热 Key 突增时怎么止血和回查
• Kafka 积压突然飙升时怎么排查
• Elasticsearch 查询突然变慢时怎么定位

6 篇文章应用运行时故障的现场与根因收敛适合把线程死锁、CPU 高、Full GC、接口超时和 OOM 现场保留放在一条运行时排障主线上看。起步文章：线程死锁现场该先保留什么证据

• 线程死锁现场该先保留什么证据
• CPU 高但系统调用不高说明什么
• Full GC 频发时先看分配还是引用链

延伸相关入口如果你已经明确问题在数据库连接、网关或磁盘资源层，继续到数据与基础设施排障专题会更快；如果你想回到原理层补 JVM、并发和线程池，可以继续到 Java 专题。