觉得对您有帮助麻烦点点关注啦您的关注是我创作的最大动力~ 第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 javaPID及CPU/内存占比3. JVM内部分析GC/线程/堆/元空间jstat -gcutil PID 1000/jstack PID/jmap -histo PIDGC频率、线程阻塞、对象分布2. 系统层面第一反应命令1top/htop看%CPU过高 → CPU密集计算 / 频繁GC / 死循环看%MEM过高 → 堆内存不足 / 内存泄漏看load average CPU核数 说明有线程排队命令2vmstat 1procs r运行队列 CPU核数 → CPU不够swap si/so0 → 物理内存不足正在换页cpu wa10% → 磁盘I/O瓶颈命令3iostat -x 1%util接近100% → 磁盘繁忙await20ms → 磁盘响应慢可能是随机读多或磁盘性能差命令4free -havailable接近0 → 物理内存不足命令5sar -n DEV 1rxkB/s / txkB/s带宽打满%ifutil接近100% → 网络I/O瓶颈3. JVM层面定位Java进程后3.1 GC问题最常见# 每1秒打印GC统计看CPU time和GC次数jstat-gcutilPID1000# 输出解读# 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 状态jstackPIDthread.dump# 快速统计线程状态grep-Ejava.lang.Thread.Statethread.dump|sort|uniq-c# 死锁检测jstack输出末尾会有 Found one Java-level deadlock常见模式大量WAITING (parking)→ 线程池空转或阻塞在锁上大量RUNNABLE且CPU低 → 可能是I/O阻塞网络/磁盘3.3 内存分布保守使用会STW# 查看存活对象分布生产谨慎会暂停应用jmap-histo:livePID|head-50# 如果某自定义类实例数异常多 → 内存泄漏点3.4 堆外内存NIO/DirectBuffer# 查看直接内存使用JDK 8u40jdk/bin/jcmdPIDVM.native_memory summary|grep-EDirect|Internal4. 应用层面根据业务特征4.1 热点代码定位工具适用场景命令Arthas阿里开源在线方法级分析不重启trace 类名 方法名/monitor/watchasync-profilerCPU/内存火焰图./profiler.sh -d 30 -f flamegraph.html PIDVisualVM开发/测试环境连接JMX看Sampler4.2 数据库瓶颈开启慢查询日志slow_query_log1long_query_time2使用EXPLAIN分析SQL关注typeALL全表扫描和ExtraUsing filesort查看数据库连接池状态如HikariCP的active/idle连接数4.3 外部依赖/中间件检查Redis/MySQL/MQ的响应时间业务日志中打印调用耗时用ping/telnet检查网络延迟用tcpdump抓包分析深层问题5. 完整诊断案例模拟场景用户反馈接口P99从50ms飙升到5秒。步骤top→ 发现某个Java进程CPU 300%4核机器top -H -p PID→ 找到CPU最高的线程ID如 0x7f3aprintf %x\n 0x7f3a→ 转十六进制7f3ajstack PID | grep -A 20 7f3a→ 看到线程堆栈在java.util.regex.Pattern.compile定位到代码循环内用Pattern.compile创建正则应改为静态常量修复提升P99到100ms。6. 性能评估指标面试必背维度核心指标正常范围告警阈值CPU系统用户等待75% 核均90% 持续5分钟内存可用内存20%10%GCYGC次数/秒3次/秒10次/秒GCFGC次数/小时0次1次/小时GCGC总耗时占比5%10%线程阻塞/等待线程数10% 总线程30%磁盘%util await%util70%, await10ms%util90%网络丢包率/重传率0.01%0.1%7. 面试官追问示例Q1CPU高但GC次数不多如何定位A用top -H -p PID找线程ID →printf %x转十六进制 →jstack PID | grep 十六进制定位代码行。常见原因死循环、正则编译、序列化/反序列化、日志打印如toString中循环。Q2GC正常但接口慢怎么查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 b0。Q5如何评估系统最大并发能力A压测JMeter/Locust观察拐点CPU达到80%RT响应时间突然飙升错误率 1%GC时间占比 10%面试官想要的满分总结“生产变慢我会按照系统资源 → 进程 → JVM → 应用代码逐层下钻。系统层用top/vmstat/iostat找出CPU/内存/IO瓶颈JVM层用jstat -gcutil看GC频率jstack看线程状态必要时用jmap或 Arthas 看对象分布应用层用 Arthastrace或火焰图定位热点代码。核心是不靠猜测用数据说话。线上变更需先压测获取基线指标TPS、RT、GC占比变慢时可对比基线快速定位差异。”觉得对您有帮助麻烦点点关注啦您的关注是我创作的最大动力~
