DeepSeek性能排查清单提示词生成指南（可发布版）

--- version: v1.2.0 publish_date: 2026-05-30 reviewed_by: SRE-Lead --- # Ja va微服务线上性能问题标准化排查清单 ## CPU飙升 | 现象识别 | 根因定位 | 验证动作 | 责任人 | |----------|----------|----------|--------| | Prometheus 指标 /actuator/prometheus 中 `system_cpu_usage` 持续 > 80% 超过 5 分钟；SkyWalking 拓扑图 http://skywalking.prod/internal 显示服务响应时间倍增 | 抓取 Arthas dashboard 输出，比对 thread 列表标识 `cpu%` > 50% 的线程；使用 `thread -n 5` 抓取最忙线程堆栈 | 抓取线程堆栈后，比对业务日志时间戳确认热点代码行；执行 `thread -b` 检查锁竞争；若关联业务线程，截取堆栈并提交给开发组【仅限生产环境值班人员执行】 | SRE 值班人员 → 开发组 | ## 内存泄漏 | 现象识别 | 根因定位 | 验证动作 | 责任人 | |----------|----------|----------|--------| | Prometheus 中 `jvm_memory_used_bytes` 持续上升，GC 回收后无下降；SkyWalking 显示 `Old Gen` 使用率 > 90% 且不回落 | 抓取 Arthas heapdump 文件：`heapdump /tmp/heap.hprof`；使用 `jmap -histo:live` 比对对象实例数 `count` 和 `bytes` 增幅 | 回滚上一小时内的代码变更；触发 Full GC 强制回收：`jstat -gc -h10` 观察 `FGC` 计数是否增加；若仍无释放，抓取堆转储文件并分析【堆转储文件存储路径 /data/dump/，保留 7 天】 | SRE 值班人员 → 开发组 lead | ## GC异常 | 现象识别 | 根因定位 | 验证动作 | 责任人 | |----------|----------|----------|--------| | Prometheus 中 `jvm_gc_pause_seconds` 指标 > 500ms 且频次 > 10 次/分钟；SkyWalking 拓扑图中服务出现 `GC overhead limit exceeded` 异常 | 执行 `jstat -gc -h10` 抓取年轻代和老年代占用、GC次数、停顿时间；使用 Arthas `memory` 命令查看各区域使用率；比对 `-Xms` 与 `-Xmx` 是否一致（若不一致，标记扩容【需P1审批】） | 调整 GC 策略参数：`-XX:+UseG1GC` `-XX:MaxGCPauseMillis=200`（修改后重启服务）【需P1审批】；执行 `jstat -gc -h10` 持续 5 分钟监控停顿时间下降至 < 200ms；比对启动参数是否已持久化到 `JA VA_OPTS` 环境变量 | SRE 高级工程师 → 架构组审批 | ## 线程阻塞 | 现象识别 | 根因定位 | 验证动作 | 责任人 | |----------|----------|----------|--------| | Prometheus 中 `tomcat_threads_busy` 接近 `tomcat_threads_max`；SkyWalking 拓扑图显示大量 `Connection timeout` 或 `Read timeout` 异常；业务日志出现 `ja va.util.concurrent.TimeoutException` | 抓取 Arthas thread 堆栈：`thread --state BLOCKED`；使用 `thread -n 5 -b` 检测死锁；比对 SkyWalking 拓扑图中依赖的上下游服务状态 | 抓取完整线程 dump：`jstack -l` 输出至文件【仅限生产环境值班人员执行】；比对 `BLOCKED` 线程数的锁对象是否为同一资源；若为数据库连接池耗尽，检查 SkyWalking 拓扑图中 DB 节点响应时间；执行 `curl -X POST http://skywalking.prod/internal/forceGC` 触发临时清理（仅限该 API 存在时） | SRE 值班人员 → 中间件组 |

来源：互联网