01

60 秒回答模板

排查性能瓶颈我会先看用户侧指标：QPS、成功率、错误率、超时率、P95/P99 延迟和是否集中在某些接口。然后看应用内部：线程池、连接池、队列积压、锁等待、GC、慢 SQL、缓存命中率和日志错误。系统资源看 CPU 使用率、load、run queue、上下文切换、内存、page fault、磁盘 I/O、网络吞吐和丢包。依赖侧看数据库、Redis、MQ、下游服务的耗时和错误。最后用 trace、火焰图和日志关联到具体慢节点，避免只凭单机 CPU 下结论。

考点 核心机制与工程取舍
难度 中高频面试题
回答目标 按定义、机制、场景讲清楚
02

深入解析

01

先确认用户影响

从入口 RED 指标看请求量、错误率和耗时分位数，尤其是 P95、P99、超时率和慢接口分布。平均值可能很好看，但长尾延迟已经让用户不可用。

02

应用内部找排队

线程池活跃数、队列长度、拒绝数、连接池等待、锁等待、协程或事件循环阻塞都能说明请求是否在应用内排队。队列堆积常常比 CPU 高更早暴露瓶颈。

03

JVM 和语言运行时

Java 服务要看 GC 次数、暂停时间、分配速率、老年代增长、Full GC、JIT 预热和线程状态。Go、Node、C++ 也要看各自运行时的 GC、事件循环、内存分配和阻塞点。

04

系统资源看 USE

CPU 要结合使用率、load、run queue、iowait 和上下文切换；内存看 RSS、缓存、swap、page fault；磁盘看 IOPS、吞吐、等待时间；网络看带宽、连接数、重传、丢包和端口耗尽。

05

依赖和链路定位

数据库慢查询、锁等待、连接耗尽，Redis 热 key、网络抖动，MQ 积压、下游超时，都可能让本服务表现为慢。分布式追踪能把一次请求拆到各服务和依赖耗时，火焰图能定位 CPU 热点。

03

易错点

  • 只看 CPU 使用率，忽略线程池排队、连接池等待和依赖耗时。
  • 只看平均响应时间，不看 P95/P99、超时率和慢接口分布。
  • 没有把业务流量变化和资源指标放在同一时间线对齐。
  • 缺少 trace 或分段耗时，无法区分本服务慢和下游慢。
04

面试官追问

为什么不能只看平均延迟？

平均值会被大量快请求稀释，掩盖少量很慢的请求。P95、P99 和超时率更能反映用户实际体验，尤其是链路长、依赖多的服务。

CPU 高怎么继续定位？

先看是用户态、内核态还是 iowait，再定位到进程和线程，结合线程栈、perf、async-profiler 或火焰图找热点方法，同时排除 GC 线程和日志刷盘等因素。

load 高但 CPU 不高可能是什么？

可能是大量任务在不可中断 I/O 等待、磁盘或网络阻塞，也可能是线程数过多造成调度压力。要看 iowait、run queue、上下文切换和具体等待栈。

怎么判断是自己慢还是依赖慢？

用 trace 分解每个 span 的耗时和错误，再结合依赖侧监控。没有 trace 时可用访问日志里的分段耗时、慢 SQL、RPC 统计和连接池等待时间做交叉验证。