大家好，我是 Mr.Sun，一名热爱技术和分享的程序员。
📖 个人博客：Mr.Sun的博客
✨ 微信公众号：「Java技术宇宙」
期待与你交流，让我们一起在技术道路上成长。
一、CPU飙升
在 Java 应用中遇到 CPU 飙升问题时，排查需遵循 “从进程到线程，从现象到代码” 的递进思路，结合系统工具和 JVM 工具定位根因。以下是详细排查步骤：
1. 定位高 CPU 占用的 Java 进程
使用top命令查看进程 CPU 使用率（默认按 CPU 排序），找到 CPU 占比异常的 Java 进程，记录其PID（进程 ID）。
示例：top命令输出中，PID列对应进程 ID，%CPU列显示 CPU 使用率，若某 Java 进程（通常进程名含java或应用名）的%CPU长期高于 80%，即为目标进程。
2. 定位进程内高 CPU 占用的线程
Java 进程由多个线程组成，需进一步定位到具体线程。
使用top -Hp
示例：top -Hp 12345（12345 为步骤 1 的 PID），找到%CPU最高的线程，其 TID 即为关键。
3. 转换线程 ID 为十六进制
JVM 的线程堆栈信息中，线程 ID 以十六进制表示，需将步骤 2 的 TID 转换为十六进制：
使用 printf "%x\n"
示例：若 TID 为 12346，执行printf "%x\n" 12346得到十六进制303a（注意小写，jstack 输出为小写）。
4. 分析线程堆栈，定位代码位置
通过jstack工具获取目标进程的线程堆栈，查找高 CPU 线程的执行逻辑：
- 执行
jstack <PID> > stack.log，将堆栈信息输出到文件（避免终端滚动丢失）。 - 在
stack.log中搜索步骤 3 得到的十六进制线程 ID（如303a），找到对应的线程堆栈。
关键关注线程状态和执行代码：
- 若线程状态为
RUNNABLE，且堆栈显示在某个方法中持续执行（如循环、大量计算），则该方法可能是 CPU 飙升的直接原因（如死循环、复杂正则匹配、高频计算等）。 - 若线程状态为
TIMED_WAITING或WAITING，但 CPU 占比高，需结合上下文（如是否频繁唤醒 / 阻塞）。
5. 常见根因总结
- 死循环 / 低效循环：如while(true)缺少退出条件，或循环内执行大量耗时操作（如字符串拼接、复杂计算）。
- 频繁 GC：内存泄漏导致对象堆积，触发高频 Full GC；或新生代设置过小，导致 YGC 频繁。
- 高频 IO / 日志：循环内大量打印日志（尤其是同步日志）、频繁读写文件 / 网络，导致 CPU 忙于 IO 处理。
- 线程竞争：虽线程状态为BLOCKED，但大量线程竞争锁时，JVM 的锁调度会消耗 CPU。
二、JVM排查
JVM 排查是 Java 应用性能问题和稳定性问题定位的核心环节，涉及内存、GC、线程、类加载等多个维度。排查需结合监控指标、工具链和日志分析，从 “现象” 反推 “根因”。以下是系统的 JVM 排查思路，覆盖常见问题场景：
基础工具与数据收集
| 工具 / 命令 | 作用 | 关键参数 / 用法示例 |
|---|---|---|
| jps | 查看本地 Java 进程 PID | jps -l（显示进程 PID 和主类名） |
| jinfo | 查看 JVM 参数、系统属性 | jinfo |
| jstat | 监控 GC、类加载等统计信息 | jstat -gc |
| jmap | 生成堆快照、查看堆内存分布 | jmap -heap |
| jstack | 生成线程堆栈，分析线程状态 | jstack |
| jconsole/jvisualvm | 可视化监控工具（堆、线程、GC 实时数据） | 直接启动jconsole，连接进程 PID 即可 |
场景 1：内存溢出（OOM）或内存泄漏
现象：应用抛出java.lang.OutOfMemoryError（如堆溢出、元空间溢出），或堆内存持续增长至上限。
排查步骤：
1. 确定 OOM 类型：通过错误日志判断是哪种溢出（关键）
- Java heap space：堆内存不足（对象太多 / 太大，无法回收）。
- Metaspace：元空间不足（类加载过多，未释放）。
- Requested array size exceeds VM limit：数组过大，超过堆上限。
2. 收集堆数据
- 若提前配置了
-XX:+HeapDumpOnOutOfMemoryError-XX:HeapDumpPath=./heap.hprof，OOM 时会自动生成堆快照，直接分析即可。 - 未配置则手动生成：
jmap -dump:format=b,file=heap.hprof <PID>（生产环境注意：dump 过程可能暂停应用几秒，建议低峰期执行）。
3. 分析堆快照
使用工具：MAT（Memory Analyzer Tool）、JProfiler、VisualVM。
- 内存泄漏定位：通过 “支配树（Dominator Tree）” 或 “泄漏嫌疑（Leak Suspects）” 报告，找到 “存活对象数异常多” 的类（如某缓存类对象占比超过 50%），检查其引用链（为何未被 GC 回收，如被静态集合强引用）。
- 大对象定位：查看 “最大对象” 列表，若存在单个超大对象（如 100MB 的 byte []），可能是业务逻辑中不合理的对象创建（如一次性加载全量数据）。
点击工具栏上的 Histogram 图标可以打开Histogram（直方图)视图，可以列出每个类产生的实例数量，以及所占用的内存大小和百分比。主界面如下图所示：
图中Shallow Heap 和 Retained Heap分别表示对象自身不包含引用的大小和对象自身并包含引用的大小;
其实从图中占用内存大小排序后,基本上就能看到那个类产生了OOM,然后从代码的角度去排查一下就好了;
4. 元空间溢出补充
若为Metaspace溢出，用jmap -clstats
- 动态生成类过多（如反射、CGLIB 代理未限制）。
- 类加载器泄漏（如 Web 应用热部署时，旧类加载器未被回收，导致类重复加载）。
场景 2：GC 异常（频繁 / 耗时过长）
现象： 应用卡顿（GC 暂停时间长）、CPU 飙升（GC 线程占用高），或jstat显示 YGC/FGC 次数异常（如每秒 10 次 YGC，或每分钟 3 次以上 FGC）。
1. 查看 GC 基础统计：
执行jstat -gcutil <PID> 1000，关注核心指标：
- S0/S1：Survivor 区使用率（若长期接近 100%，可能是 Survivor 区太小，对象直接进入老年代）。
- E：Eden 区使用率（若频繁满，YGC 频繁，可能是 Eden 区太小或对象创建太快）。
- O：老年代使用率（若持续增长至 100%，触发 FGC，可能是内存泄漏或大对象直接进入老年代）。
- YGC/YGCT：Young GC 次数 / 总耗时（秒）（单次 YGCT 超过 50ms 需警惕）。
- FGC/FGCT：Full GC 次数 / 总耗时（秒）（单次 FGCT 超过 1 秒会导致应用卡顿，需紧急处理）。
2. 分析 GC 日志
若未开启 GC 日志，临时配置（需重启应用，生产环境建议默认开启）：
-XX:+PrintGCDetails -XX:+PrintGCDateStamps -XX:+PrintGCApplicationStoppedTime -Xloggc:./gc.log
用工具分析日志：GCEasy（在线工具）、GCViewer（本地工具），重点看：
- GC 原因：FGC 是否因 “老年代满”（Allocation Failure）或 “元空间满”（Metadata GC Threshold）。
- 暂停时间：是否有单次 GC 暂停超过业务容忍阈值（如 1 秒）。
- 对象晋升：Young GC 后晋升到老年代的对象大小（若超过老年代剩余空间，会触发 FGC）。
3. 根因判断
- YGC 频繁：Eden 区设置过小（调大-Xmn）；应用创建对象速度过快（如循环内 new 大量临时对象，优化代码复用）。
- FGC 频繁：老年代内存泄漏（参考场景 1 排查）；大对象直接进入老年代（调大-XX:PretenureSizeThreshold，让大对象先在新生代回收）；GC 收集器不匹配（如 CMS 收集器在高并发下容易碎片化，可切换为 G1）。
JVM 参数调优辅助排查
很多 JVM 问题源于参数配置不合理，排查时需结合jinfo -flags <PID>检查关键参数：
- 堆大小：-Xms（初始堆）、-Xmx（最大堆）是否过小（如小于应用实际需求），或-Xms != -Xmx导致堆频繁扩容。
- 新生代 / 老年代比例：-XX:NewRatio（默认 2，老年代：新生代 = 2:1）、-Xmn（新生代大小）是否匹配对象生命周期（短生命周期对象多应调大新生代）。
- GC 收集器：-XX:+UseG1GC、-XX:+UseConcMarkSweepGC等，需结合应用特点（如低延迟选 G1，高吞吐量选 Parallel）。
三、JVM参数
- -D 可以是系统默认有的参数，也可以是自己定义的参数
-Dfile.encoding=UTF-8
-Dmaven.test.skip=true
-Dspring.profiles.active=test
-Dhsf.server.port=12404
-Dhsf.http.port=12402
- 堆内存参数
-Xmx5M 指定最大堆内存。 如 -Xmx4g。这只是限制了 Heap 部分的最大值为4g。这个内存不包括栈内存，也不包括堆外使用的内存，默认是物理内存的1/4。
-Xms5M 指定堆内存空间的初始大小。 如 -Xms4g。 而且指定的内存大小，并不是操作系统实际分配的初始值，而是 GC 先规划好，用到才分配。 专用服务器上需要保持 –Xms 和 –Xmx 一致，否则应用刚启动可能就有好几个FullGC。当两者配置不一致时，堆内存扩容可能会导致性能抖动，默认是物理内存的1/64。
-Xmn: 设置年轻代大小，等价于 -XX:NewSize，使用 G1 垃圾收集器不应该设置该选项，在其他的某些业务场景下可以设置。官方建议设置为 -Xmx 的 1/2 ~ 1/4。
-Xss：设置每个线程栈的字节数，影响栈的深度。例如 -Xss1m 指定线程栈为1MB，与-XX:ThreadStackSize=1m 等价。
- GC 设置参数
-XX:+UseConcMarkSweepGC：使用 CMS 垃圾回收器。
-XX:+UseSerialGC：使用串行垃圾回收器。
-XX:+UseParallelGC：使用并行垃圾回收器。
-XX:+UnlockExperimentalVMOptions -XX:+UseZGC： jdk 11 以上开启 ZGC.
-XX:+UnlockExperimentalVMOptions -XX:+UseShenandoahGC：jdk 12 以上开启 ShenandoahGC。
- 分析诊断参数
-XX:+HeapDumpOnOutOfMemoryError：当 OutOfMemoryError 产生，即内存溢出（堆内存或持久代/元空间) 时，自动 Dump 堆内存。
-XX:HeapDumpPath：与 HeapDumpOnOutOfMemoryError 搭配使用，指定内存溢出时 Dump 文件的目录。如果没有指定则默认为启动 Java 程序的工作目录。
java -Xmx5m -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/log/dump HeapOOM
自动 Dump 的 hprof 文件会存储到 /log/dump 目录下。
作者：Mr.Sun | 「Java技术宇宙」主理人
专注分享硬核技术干货与编程实践，让编程之路更简单。
📖 深度文章：个人博客「Mr.Sun的博客」
🚀 最新推送：微信公众号「Java技术宇宙」
