很多同学面试被问到线上 OOM 了怎么办张嘴就是调大堆内存。这就像车坏了你说多加点油——方向完全错了。JVM 调优的核心不是背参数而是先定位根因再对症下药。这篇用三个线上最高频的问题把排查链路从头到尾走一遍。一、JVM 调优到底在调什么先搞清楚目标。JVM 调优有三个核心指标它们是不可能三角吞吐量单位时间能处理多少请求离线任务看重延迟单次请求响应时间在线接口看重内存占用堆内存大小资源成本调优就是在你的业务场景下找平衡点。搞清楚目标再动手。二、问题一OOM 内存溢出OOM 是最常见的 JVM 故障。先看一段可以直接跑的复现代码。堆 OOM 复现代码publicclassOomDemo{staticclassUser{Stringname;byte[]data;User(Stringn){namen;datanewbyte[1024*1024];}}publicstaticvoidmain(String[]args){ListUserlistnewArrayList();intcount0;while(true){list.add(newUser(usercount));count;}}}用小堆运行强制触发 OOMjava-Xmx32m-Xms32mOomDemo.java运行输出已创建 10 个对象... 捕获 OOM: Java heap space看到Java heap space说明是堆内存不够了。但 OOM 不止这一种不同类型排查方向完全不同。OOM 类型对照表OOM 类型典型原因排查方向Java heap space堆不足、内存泄漏、大对象dump 堆快照分析Metaspace动态生成类过多CGLIB/反射调大 MaxMetaspaceSize、查类加载器泄漏GC overhead limitGC 耗时超 98% 但回收不到 2%通常伴随堆泄漏先查堆Direct buffer memory堆外内存Netty/NIO泄漏调大 MaxDirectMemorySize、查堆外引用unable to create new native thread线程数超限查线程池配置、ulimit堆 OOM 排查标准四步第一步导出堆快照jmap-dump:formatb,fileheap.hprofpid生产环境加live参数只 dump 存活对象文件更小。第二步用Eclipse MAT最常用或 jhat 打开快照看 Dominator Tree找出占用内存最大的对象和它的 GC Roots 引用链——谁在持有它、为什么回收不掉。第三步同时用 jstat 看 GC 趋势确认是不是内存持续上涨jstat-gcutilpid1000第四步定位到代码后修复。生产环境务必加这个参数OOM 时自动留证-XX:HeapDumpOnOutOfMemoryError -XX:HeapDumpPath/path/to/dump顺带说栈溢出 StackOverflowError栈溢出不是 OOM但同样高频。递归没有终止条件时必现staticvoidrecursive(intdepth){recursive(depth1);// 无终止条件}运行输出StackOverflowError。排查看异常栈里重复的方法调用找到递归点。调大-Xss只是缓解根本要修递归逻辑。三、问题二CPU 飙高 100%线上 CPU 打满是最紧急的故障。记住这个四步排查法面试和线上都用得上。第一步找到最耗 CPU 的线程。top-Hppid这会列出 Java 进程下所有线程按 CPU 排序记下最耗 CPU 的线程 ID比如 12360。第二步把线程 ID 转成十六进制。printf%x\n12360输出3048。因为 jstack 里的线程 IDnid是十六进制表示的。第三步导出线程栈。jstackpidthread.txt第四步在栈里搜这个十六进制 ID。grep-A203048thread.txt就能看到这个线程正在执行哪段代码。CPU 飙高常见根因根因特征解决死循环某个线程 CPU 持续 100%jstack 看线程栈定位循环频繁 Full GCGC 线程耗 CPU业务卡顿先解决内存问题锁竞争大量 BLOCKED 线程优化锁粒度正则回溯复杂正则匹配大文本优化正则、加超时四、问题三频繁 Full GC频繁 Full GC 会导致 STWStop The World接口大量超时。用 jstat 一眼就能看出来jstat-gcutilpid10003输出示例S0 S1 E O M YGC YGCT FGC FGCT GCT 0.00 98.20 95.12 99.80 92.10 120 12.345 45 89.123 101.468 0.00 98.20 95.12 99.80 92.10 120 12.345 46 91.234 103.579 0.00 98.20 95.12 99.80 92.10 120 12.345 47 93.456 105.799看三个关键信号老年代O 持续 99.8%、FGC 每秒涨一次、FGCT 快速累积。而且 Full GC 后老年代占用不降——这就是典型的内存泄漏对象回收不掉。频繁 Full GC 常见原因原因判断特征解决内存泄漏Full GC 后老年代不降反升dump 堆MAT 找泄漏点大对象直接进老年代年轻代频繁 YGC调大 PretenureSizeThreshold元空间不足M 区满触发 Full GC调大 MaxMetaspaceSize年轻代太小对象过早晋升调大 -XmnSystem.gc() 调用代码显式触发加 -XX:DisableExplicitGC常见内存泄漏点静态集合只加不清、ThreadLocal 用完不 remove、监听器注册了不注销、缓存没有上限。五、常用调优参数速查参数作用建议-Xms / -Xmx初始堆 / 最大堆生产设相同值避免动态扩缩-Xmn年轻代大小通常堆的 1/3 ~ 1/2-XX:SurvivorRatioEden:Survivor 比例默认 88:1:1-XX:MaxTenuringThreshold晋升老年代年龄默认 15-XX:UseG1GC使用 G1 收集器JDK9 默认大堆推荐-XX:MaxGCPauseMillisG1 目标停顿默认 200ms按业务调-XX:DisableExplicitGC禁用 System.gc()建议开启-XX:HeapDumpOnOutOfMemoryErrorOOM 自动 dump生产必开六、调优四步法核心心法不管什么问题都按这个顺序来监控jstat / top / 监控平台先看现象和指标定位jstack / jmap dump / MAT找到根因调优先改代码再调参数一次只改一个变量验证压测对比看指标是否改善最忌讳的就是上来就改一堆参数最后不知道哪个起了作用、哪个引入了新问题。口诀先监控来后定位jstat jstack 加 dumpOOM 看类型分区域CPU 找线程转十六Full GC 频繁查泄漏老年代不降是关键先改代码后调参一次一变再压验。到这里JVM 四大模块内存结构、垃圾回收、类加载、调优实战就全部收尾了。下一站进入并发编程synchronized / volatile / 线程池 / JUC / ThreadLocal。觉得有用点个赞、关注一下咱们并发篇见。#Java #JVM #JVM调优 #OOM #Java面试 #后端开发 #性能优化