【大白话说Java面试题 第67题】【JVM篇】第27题：生产环境服务器变慢，诊断思路和性能评估谈谈？

---

觉得对您有帮助，麻烦 点点关注啦 ，您的关注是我创作的最大动力~ 🎯

第27题：生产环境服务器变慢，诊断思路和性能评估谈谈

📚 回答：

• 核心考点 ：
  大厂面试要求具备系统性的故障诊断能力 ，从硬件→OS→JVM→应用→中间件逐层下钻，并能用具体命令和工具定位根因。不能只说"查日志看CPU"。

---

1. 标准诊断流程（三板斧）

步骤	目标	核心命令/工具	输出解读
1. 系统概览	CPU/内存/IO/网络谁最紧张	top / htop / vmstat 1 / iostat -x 1 / sar -n DEV 1	定位瓶颈维度
2. 进程定位	哪个Java进程有问题	top -p <PID> / `ps aux	grep java`
3. JVM内部分析	GC/线程/堆/元空间	jstat -gcutil <PID> 1000 / jstack <PID> / jmap -histo <PID>	GC频率、线程阻塞、对象分布

---

2. 系统层面（第一反应）

命令1：top / htop

• 看 %CPU（过高 → CPU密集计算 / 频繁GC / 死循环）
• 看 %MEM（过高 → 堆内存不足 / 内存泄漏）
• 看 load average（ > CPU核数 说明有线程排队）

命令2：vmstat 1

• procs r（运行队列 > CPU核数 → CPU不够）
• swap si/so（>0 → 物理内存不足，正在换页）
• cpu wa（>10% → 磁盘I/O瓶颈）

命令3：iostat -x 1

• %util（接近100% → 磁盘繁忙）
• await（>20ms → 磁盘响应慢，可能是随机读多或磁盘性能差）

命令4：free -h

• available 接近0 → 物理内存不足

命令5：sar -n DEV 1

• rxkB/s / txkB/s（带宽打满？）
• %ifutil（接近100% → 网络I/O瓶颈）

---

3. JVM层面（定位Java进程后）

3.1 GC问题（最常见）

# 每1秒打印GC统计，看CPU time和GC次数
jstat -gcutil <PID> 1000

# 输出解读：
# S0/S1/E/O/M 使用率（如果O老年代持续>90%且不降 → 内存泄漏/堆太小）
# YGC / YGCT → Young GC次数/总耗时（频繁 >5次/秒 → Eden太小）
# FGC / FGCT → Full GC次数/总耗时（>1次/分钟 → 严重）

典型案例：

• FGC频繁但老年代占用不高 → 元空间触发Full GC（-XX:MetaspaceSize太小）
• FGC频繁 + 老年代占满 → 堆内存泄漏或峰值

3.2 线程问题（死锁/阻塞）

# 打印线程栈，重点关注 BLOCKED / WAITING 状态
jstack <PID> > thread.dump

# 快速统计线程状态
grep -E "java.lang.Thread.State" thread.dump | sort | uniq -c

# 死锁检测（jstack输出末尾会有 "Found one Java-level deadlock"）

常见模式：

• 大量 WAITING (parking) → 线程池空转或阻塞在锁上
• 大量 RUNNABLE 且CPU低 → 可能是I/O阻塞（网络/磁盘）

3.3 内存分布（保守使用，会STW）

# 查看存活对象分布（生产谨慎，会暂停应用）
jmap -histo:live <PID> | head -50

# 如果某自定义类实例数异常多 → 内存泄漏点

3.4 堆外内存（NIO/DirectBuffer）

# 查看直接内存使用（JDK 8u40+）
jdk/bin/jcmd <PID> VM.native_memory summary | grep -E "Direct|Internal"

---

4. 应用层面（根据业务特征）

4.1 热点代码定位

工具	适用场景	命令
Arthas（阿里开源）	在线方法级分析，不重启	trace <类名> <方法名> / monitor / watch
async-profiler	CPU/内存火焰图	./profiler.sh -d 30 -f flamegraph.html <PID>
VisualVM	开发/测试环境	连接JMX，看Sampler

4.2 数据库瓶颈

• 开启慢查询日志：slow_query_log=1 + long_query_time=2
• 使用 EXPLAIN 分析SQL，关注 type=ALL（全表扫描）和 Extra=Using filesort
• 查看数据库连接池状态（如HikariCP的 active / idle 连接数）

4.3 外部依赖/中间件

• 检查Redis/MySQL/MQ的响应时间（业务日志中打印调用耗时）
• 用 ping / telnet 检查网络延迟
• 用 tcpdump 抓包分析（深层问题）

---

5. 完整诊断案例模拟

场景：用户反馈接口P99从50ms飙升到5秒。

步骤：

1. top → 发现某个Java进程CPU 300%（4核机器）
2. top -H -p <PID> → 找到CPU最高的线程ID（如 0x7f3a）
3. printf "%x\n" 0x7f3a → 转十六进制 7f3a
4. jstack <PID> | grep -A 20 "7f3a" → 看到线程堆栈在 java.util.regex.Pattern.compile
5. 定位到代码：循环内用 Pattern.compile 创建正则（应改为静态常量）
6. 修复：提升P99到100ms。

---

6. 性能评估指标（面试必背）

维度	核心指标	正常范围	告警阈值
CPU	系统+用户+等待	<75% 核均	>90% 持续5分钟
内存	可用内存	>20%	<10%
GC	YGC次数/秒	<3次/秒	>10次/秒
GC	FGC次数/小时	0次	>1次/小时
GC	GC总耗时占比	<5%	>10%
线程	阻塞/等待线程数	<10% 总线程	>30%
磁盘	%util + await	%util<70%, await<10ms	%util>90%
网络	丢包率/重传率	<0.01%	>0.1%

---

7. 面试官追问示例

Q1：CPU高但GC次数不多，如何定位？

A：用 top -H -p <PID> 找线程ID → printf "%x" 转十六进制 → jstack <PID> | grep 十六进制 定位代码行。常见原因：死循环、正则编译、序列化/反序列化、日志打印（如toString中循环）。

Q2：GC正常但接口慢，怎么查？

A：可能原因：

• 数据库慢查（看连接池活跃连接数、慢日志）
• 外部依赖超时（检查RestTemplate/Feign超时配置）
• 锁竞争（jstack 找 BLOCKED 线程）
• CPU被其他进程占用（top 看 %st 虚拟机偷取）

Q3：生产环境不让用jmap怎么办？

A：用 jstat -gcutil 看趋势；用 -XX:+HeapDumpOnOutOfMemoryError 被动dump；或用 Arthas 的 heapdump 命令（不暂停）。

Q4：服务器load高但CPU低，什么原因？

A：典型I/O瓶颈 （磁盘、网络）。进程在等待I/O，大量线程处于UNINTERRUPTIBLE状态（D状态），vmstat 会看到 procs b >0。

Q5：如何评估系统最大并发能力？

A：压测（JMeter/Locust），观察拐点：

• CPU达到80%
• RT（响应时间）突然飙升
• 错误率 >1%
• GC时间占比 >10%

---

💡 面试官想要的满分总结：

"生产变慢，我会按照 系统资源 → 进程 → JVM → 应用代码 逐层下钻。
系统层 用 top/vmstat/iostat 找出CPU/内存/IO瓶颈；
JVM层 用 jstat -gcutil 看GC频率，jstack 看线程状态，必要时用 jmap 或 Arthas 看对象分布；
应用层 用 Arthas trace 或火焰图定位热点代码。

核心是：不靠猜测，用数据说话。线上变更需先压测获取基线指标（TPS、RT、GC占比），变慢时可对比基线快速定位差异。"

---

觉得对您有帮助，麻烦 点点关注啦 ，您的关注是我创作的最大动力~ 🎯