面试官问JVM调优你张口就是-Xms、-Xmx、-XX:UseG1GC背得滚瓜烂熟。对方听完面无表情地在本子上画了个圈。这个圈的意思是这人背过八股文但没真调过。JVM调优不是参数默写比赛是诊断思维和工程判断的较量。能把参数背出来的人一抓一把能讲清楚“为什么调、怎么定位、调完效果如何”的人才是面试官想聊下去的对象。别上来就谈参数先问一句“出了什么问题”调优的前提是故障。没有病吃什么药面试时遇到“你怎么调优”这种问题先反问场景是频繁Full GC导致停顿过长还是内存溢出OOM还是CPU飙高伴随GC线程占满不同症状对应不同药方。吞吐量优先的应用和响应时间优先的应用GC策略截然不同。不问症状就开药是庸医不问场景就调参是莽夫。老子说“知人者智自知者明”调优的第一步是自知——知道系统到底病在哪。GC日志是唯一的证据不是感觉很多人调优靠“感觉”觉得堆越大越好觉得G1一定比CMS强。这是拍脑袋。正确的做法是开启GC日志-Xlog:gc:filegc.log:time,uptime,level,tags然后用GCViewer或GCEasy分析。看什么看Young GC频率、Full GC次数、单次停顿时间、晋升老年代速率。如果Young GC每秒好几次说明新生代太小如果Full GC频繁且每次回收不了多少说明有内存泄漏。数据不会说谎感觉会。面试时你能说出“我先看GC日志里的Allocation Failure和Humongous Allocation”面试官就知道你亲手干过。内存泄漏和内存溢出两码事OOM分两种堆内存溢出和元空间溢出。堆溢出可能是泄漏也可能是真不够。泄漏的典型特征是每次Full GC后老年代占用不降反升。用jmap dump堆快照MAT或JProfiler找支配树定位哪个对象持有大量引用。元空间溢出多半是动态生成类太多比如CGLIB代理滥用。别把泄漏当不够加内存只能拖延崩溃不能根治。面试时区分清楚这两者是基本功。调优的终点是业务指标不是GC指标GC停顿从200ms降到50ms然后呢业务QPS提升了吗TP99下降了吗如果GC优化了但业务没变说明瓶颈根本不在这里。JVM调优永远服务于业务目标。响应时间敏感的系统优先选低停顿收集器比如ZGC或Shenandoah吞吐量敏感的系统Parallel GC可能更合适。脱离业务谈调优就像脱离战场谈兵法纸上谈兵。面试时你能把GC指标和业务SLA挂钩层次立刻不一样。一个真实案例胜过十页理论准备一个你亲手调优的案例。比如某服务每天凌晨Full GC持续十几秒观察发现是老年代有个定时任务加载全量数据到本地缓存导致对象朝生夕死却晋升老年代。解决方案是改成本地缓存加弱引用或者调整Survivor区比例让短命对象留在新生代。最后Full GC从每天十几次降到几天一次。案例要讲清楚现象、工具、分析、决策、结果。这才是STAR法则在JVM调优里的应用。面试官眼前一亮是因为你展现了思维过程参数可以查工具可以学但诊断思维和权衡取舍的能力是查不来的。面试官想听的是你如何从现象出发用工具验证假设再根据业务约束做选择。调优不是炫技是带着镣铐跳舞。内存、CPU、延迟、吞吐量四个维度互相拉扯你要找到当前场景下的最优解。能把这个过程讲清楚的人面试官自然会给出那个圈——不是画掉你是圈定你。