交付一份「Java 线上 P99 延迟突增排查 SOP」markdown 文档

Java 线上 P99 延迟突增排查 SOP（v1.0）

作者：程景行-547｜适用场景：Java 微服务（Spring Boot / Dubbo / gRPC）P99 从稳态突然跳升 2x–10x，持续 10s 以上。 核心原则：先圈范围、再分层切、最后锁根因。把 P99 突增想象成"一条高速公路上突然塞了一辆车"——你要先确认是整条路堵了还是某个匝道堵了，再逐段查。

一、黄金 30 秒：圈范围

目标：30 秒内回答"谁堵了"

# 1. 看全局：这条链路上所有服务的 P99 曲线（Grafana 面板）
#    关注"谁先动"——先跳的服务是根因候选，后跳的是受害者
prometheus:
  histogram_quantile(0.99,
    sum(rate(http_server_request_duration_seconds_bucket{service="order-service"}[5m])) by (le))

# 2. 是全局还是局部？
#    全局 P99 都涨 → 大概率是共享资源（DB / Redis / 网络）
#    只某服务涨 → 大概率是应用自身（GC / 线程池 / 代码路径）
prometheus:
  topk(10, histogram_quantile(0.99, sum(rate(http_server_request_duration_seconds_bucket[5m])) by (service, le)))

# 3. 是否所有实例都涨？
#    单实例涨 → 该实例 GC / 热部署 / 邻居干扰
#    全实例涨 → 共享依赖 / 流量结构变化 / 配置推送

判据速查： | 现象 | 最可能根因 | 跳转 | |------|-----------|------| | 全服务 P99 同时涨 3s+ | DB 慢查询 / 网络 / DNS | → §三 | | 仅本服务涨，QPS 不变 | GC / 线程池 / 锁 | → §二 | | 仅本服务涨，QPS 也变了 | 流量结构 / 上游重试 | → §四 | | 单实例涨 | 实例级 GC / 邻居 / 内核 | → §五 | | P99 涨但 P50 没涨 | 长尾路径（大 key / 慢 SQL / 锁等待） | → §二.3 |

二、应用层：JVM 与线程（最常见元凶）

2.1 GC 风暴

比方：GC 就像"系统突然全员停工 200ms 去整理仓库"——活没干完但人全停了。

# 实时看 GC 停顿（JDK 11+）
jstat -gcutil <pid> 1000 10
# 关注 FGC 次数是否突增、FGCT 是否在涨

# 看最近一次 GC 日志（-Xlog:gc*:file=gc.log）
grep "Pause" gc.log | tail -20
# 典型输出：
# [gc 412.318s] GC(2847) Pause Young (Normal) (G1 Evacuation Pause) 2048M->512M(2048M) 87.3ms
# 如果看到 200ms+ 停顿 + 频率 > 1/s → GC 是根因

# GC 频率告警（Prometheus + JMX Exporter）
rate(jvm_gc_pause_seconds_count{gc="young"}[5m]) > 2  # 每秒 > 2 次年轻代 GC

处置：

• 如果是堆内存泄漏 → jmap -histo:live <pid> | head -30 看 Top 对象
• 如果是 Metaspace / CodeCache 满 → 检查动态代理 / Groovy 脚本
• 如果是流量突增导致对象分配率飙升 → 看上游 QPS 是否异常

2.2 线程池打满

比方：餐厅只有 10 个服务员，突然来了 200 桌客人——不是每个菜都慢，是排队时间变长了。

# Spring Boot Actuator 看线程池
curl -s localhost:8080/actuator/metrics/jvm.threads.live
curl -s localhost:8080/actuator/metrics/jvm.threads.peak

# 抓线程快照（3 次，间隔 1s，找 BLOCKED/WAITING 线程）
jstack <pid> > t1.log; sleep 1; jstack <pid> > t2.log
# 找同一线程反复出现的锁
grep -A5 "BLOCKED" t1.log | head -40

# 自定义线程池指标（推荐埋点）
# ThreadPoolExecutor 的 queue.size() 和 activeCount
# > queue.size() / queue.capacity() > 0.8 → 即将打满

判据：

• queue.size() 持续 > 80% capacity → 线程池是瓶颈
• 大量线程 BLOCKED 在同一把锁 → 代码级锁竞争
• 大量线程 WAITING on ConnectionPool → 下游连接池耗尽（跳到 §三）

2.3 慢路径 / 大对象序列化

P99 涨但 P50 不涨 → 长尾请求：

# Arthas 抓最慢的请求
# 1. 找到慢方法
trace com.example.service.OrderService createOrder '#cost > 200'
# 输出：
# `---[234.5ms] com.example.mapper.OrderMapper#insert
# `---[180.2ms] com.example.service.Notifier#send
# 2. 看是 DB 慢还是 RPC 慢

# 大 JSON 序列化（响应体 > 1MB）
# 在 access log 里看 response_size
awk '{print $10}' access.log | sort -n | tail -20

三、共享依赖：DB / Redis / 网络

3.1 MySQL 慢查询

比方：10 个厨师共用一个灶台，一个人炖了锅 3 小时的汤——其他人全在排队等锅。

-- 实时看正在执行的慢查询
SHOW FULL PROCESSLIST;
SELECT id, time, state, info FROM information_schema.processlist WHERE time > 2;

-- 最近 1 分钟慢查询（MySQL 8.0）
SELECT event_time, sql_text, timer_wait/1000000000 AS duration_ms
FROM performance_schema.events_statements_history
WHERE timer_wait > 2000000000  -- 2s
ORDER BY event_time DESC LIMIT 20;

-- 锁等待（InnoDB）
SELECT * FROM performance_schema.data_lock_waits;
SELECT r.trx_id waiting, r.trx_mysql_thread_id, b.trx_id blocking
FROM information_schema.innodb_trx r JOIN information_schema.innodb_trx b
  ON b.trx_id = r.trx_mysql_thread_id;

常见模式：

• 索引变更 → 回表量暴涨（rows_examined / rows_sent > 100）
• 大事务持锁 → 后续 INSERT/UPDATE 排队
• 连接池 maxLifetime 缩短 → 重建连接频率上升 → 每次重建多 50-200ms

3.2 Redis 大 Key / 慢命令

# 实时慢日志
redis-cli --intrinsic-latency 10  # 客户端侧延迟
redis-cli SLOWLOG GET 20

# 大 Key 扫描（生产环境用 --no-auth-warning）
redis-cli --scan --pattern "*" | xargs -I{} redis-cli MEMORY USAGE {} | sort -k2 -rn | head -20

# 阻塞命令检测
redis-cli MONITOR | grep -E "KEYS|SMEMBERS|HGETALL|LRANGE" | head -20
# 任何 O(N) 命令在 > 10k 元素的集合上都会阻塞

3.3 网络层：DNS / conntrack / TCP

# DNS 解析耗时
time dig order-service.internal +stats
# 如果 > 50ms → DNS 是瓶颈（K8s 集群常见）

# conntrack 水位
cat /proc/sys/net/netfilter/nf_conntrack_count
cat /proc/sys/net/netfilter/nf_conntrack_max
# 使用率 > 80% → 预警；> 95% → 新连接开始被丢

# TCP 重传率
netstat -s | grep -i retrans
# 或 nstat -az | grep TcpRetransSegs
# 重传率 > 0.5% → 网络层有问题

四、流量与上游

# QPS 是否异常突增？
rate(http_server_requests_seconds_count{service="order-service"}[1m])

# 上游是否有重试风暴？
# 看同一 traceId 是否出现多次
grep "<traceId>" access.log | wc -l

# 流量结构变化（某接口占比突增）
sum by (uri) (rate(http_server_requests_seconds_count{service="order-service"}[5m]))

判据： 如果 P99 涨 + QPS 涨 + 某 URI 占比 > 3x 历史 → 流量结构变化，不是代码问题。

五、实例级 / 内核

# CPU 是否被邻居抢占（K8s 混部）
pidstat -p <pid> 1 5
# user% + sys% < 预期 → 可能被 CPU throttling
cat /sys/fs/cgroup/cpu/cpu.stat  # cgroups v1
# nr_throttled 在涨 → CPU 限流

# 磁盘 IO 等待
iostat -x 1 5
# await > 10ms → 磁盘慢（日志写盘 / 本地文件）

# 内核 softirq 丢包
netstat -s | grep -i "dropped\|overflow"
# 或 nstat -az | grep -i drop

六、排查决策树（一页速查）

P99 突增
├─ 全服务都涨？
│  ├─ 是 → DB 慢查询？Redis 阻塞？DNS/conntrack？
│  └─ 否 → 本服务
│     ├─ 全实例都涨？
│     │  ├─ 是 → GC？线程池？连接池？
│     │  └─ 否 → 单实例 GC / CPU throttling / 磁盘 IO
│     └─ QPS 也变了？
│        ├─ 是 → 流量结构 / 上游重试
│        └─ 否 → 代码路径 / 依赖调用
└─ P50 也涨？
   ├─ 是 → 全局资源瓶颈
   └─ 否 → 长尾路径（大 key / 慢 SQL / 锁）

七、预防体系（把"事后救火"变"事前预警"）

1. P99 趋势告警（非绝对阈值）：

   # 周环比 P99 涨幅 > 20% 且持续 3 天
   (histogram_quantile(0.99, sum(rate(http_server_request_duration_seconds_bucket[7d])) by (le))
    /
   histogram_quantile(0.99, sum(rate(http_server_request_duration_seconds_bucket[14d] offset 7d)) by (le))
   - 1) > 0.2
   

2. 先导指标看板（比 P99 早 1-2 天暴露）：

   • GC 频率 / 暂停时间趋势
   • 连接池 pending 趋势
   • DB rows_examined / rows_sent 比值
   • 响应体大小趋势

3. 发布级性能回归：每次发版自动跑 P99 对比（样本 > 1000 请求，Mann-Whitney U 检验 p < 0.05 判定显著劣化）

4. SLO 错误预算：核心接口 P99 SLO = 200ms，月度错误预算用尽 → 冻结发布

八、真实案例：一次"三次无害改动叠加"的 P99 劣化

时间线： 6 周内 P99 从 120ms → 300ms，全程无告警。

归因： | 改动 | 单独影响 | 叠加后 | |------|---------|--------| | 索引变更（回表量 3x） | P99 +15ms | 累积 | | 连接池 maxLifetime 30m→15m（重建频率 2x） | P99 +20ms | 累积 | | 序列化升级（响应体 +40%） | P99 +35ms | 累积 | | 合计 | 单独都"达标" | P99 +70ms（2.5x） |

教训： 单次改动在压测里"达标"≠ 叠加后不劣化。必须有趋势告警 + 发布级回归双保险。

文档版本 v1.0｜作者：程景行-547｜最后更新：2026-10-21 适用：JDK 8/11/17、Spring Boot 2.x/3.x、MySQL 5.7/8.0、Redis 6/7、K8s 1.22+