JVM 是 Java 后端面试里的常客，但很多回答停在“堆、栈、方法区”和几个参数名。真正被深挖时，面试官通常会把问题拉到线上：服务突然变慢，是不是 GC？内存一直涨，怎么判断泄漏？CPU 高时看什么？
这类题的关键，不是背出更多名词，而是能把 JVM 知识变成证据链。线上问题很少会主动告诉你“我是 Full GC 导致的”，你要从监控、日志、线程栈、堆对象和发布变更里一步步缩小范围。
先区分现象，不要一上来调参数
服务变慢不等于 GC，内存上涨也不等于泄漏。更成熟的排查会先看现象：接口耗时是否整体升高，CPU 是否打满，Young GC 是否频繁，Full GC 是否出现，线程数是否异常，错误率是否同步上升。
如果只是某个接口慢，更可能是下游、锁等待、慢 SQL 或外部调用。如果全站抖动且伴随停顿时间上升，再重点看 GC。这个顺序很重要，因为一上来就调堆大小，可能只是把真正的问题藏得更久。
GC 日志要回答三个问题
看 GC 日志不是为了展示工具熟练，而是回答三个问题：回收前后内存变化是否合理，停顿时间是否影响业务，GC 频率是否异常。
如果 Young GC 很频繁，可能是对象分配过快，也可能是新生代空间不合适；如果 Full GC 后老年代仍然降不下来，就要怀疑长生命周期对象、缓存无上限、集合持有引用、线程本地变量未清理等问题。这里不要把所有问题都归结成“内存泄漏”，因为有些只是短时间流量上涨或批处理对象太大。
工具只是入口，结论要闭环
面试里可以提 jstat、jmap、jstack、GC 日志、Arthas、监控平台，但不要只报工具名。更有价值的是说明工具解决什么问题：jstack 看线程是否阻塞或死锁，堆 dump 看哪些对象占用大，GC 日志看停顿和回收效果，链路监控看慢在哪一段。
一次完整表达可以是：我会先从监控确认是 CPU、内存、线程还是下游耗时；如果怀疑 GC，再看 GC 日志和堆使用趋势；如果 Full GC 后内存回落不明显，就抓堆快照分析大对象和引用链；修复后观察停顿时间、接口耗时和错误率是否恢复。
参数调优要说代价
JVM 参数不是越大越好。堆调大可能减少 GC 频率，但单次停顿可能更长；线程数调大可能提高并发，也可能增加上下文切换和下游压力；直接换收集器也要结合 JDK 版本、停顿目标和吞吐要求。
面试里如果被问“怎么优化 GC”，不要只说调 Xms、Xmx。先说业务目标：是降低停顿，还是提高吞吐，还是避免 OOM。再结合证据决定调整。没有证据的调参，只是在碰运气。
让 JVM 回到项目里
如果简历里写了高并发、缓存、批量导入、定时任务，就很容易被问 JVM。可以提前准备一个项目里的内存风险点：缓存是否有容量，批处理是否分批，异步队列是否堆积，大对象是否重复创建，日志是否过量拼接。
JVM 题答得好，不是因为你背得多，而是因为你能把运行时现象和业务代码联系起来。面试官听到“我会用证据判断，而不是直接调参数”，通常会更愿意继续追问项目细节。