开头先给结论JVM 这块内容大厂面试真正要考察的并不是你能背出几条命令而是你能否把内存模型、GC、STW、线上诊断工具和高并发场景串成一条完整链路。比如面试官问你 G1 和 CMS 的区别不是等你背参数而是想听你判断“什么场景下选谁、STW 压到多少算合理、线上 OOM 之后第一步做什么”。这篇文章会围绕 JVM 内存模型、GC 收集器、STW 问题、Arthas 调优和高并发电商项目实战把大厂面试题里最容易卡人的点拆开讲清楚。我自己见过不少准备 JVM 面试的人堆栈溢出、类加载、可达性分析这些概念背得很熟但一碰到“线上系统频繁 Full GC 怎么排查”“Docker 里部署的 Java 程序异常重启后日志去哪找”这类场景题就接不住。原因很简单没有把知识点变成排错动作。所以这篇内容我会按“概念 → 参数 → 实战 → 排错”的顺序来写适合正在准备大厂面试的 Java 工程师也适合工作中需要处理线上 JVM 问题的后端开发。1. 先分清 JDK、JRE、JVM再谈内存模型1.1 这道“送分题”为什么总有人答错很多面试资料把 JDK、JRE、JVM 的区别列为最基础的一题但真到面试时反而有不少人说不清楚。JVM 是 Java Virtual MachineJava 虚拟机负责把字节码解释或编译成机器指令来执行。JRE 是 Java Runtime EnvironmentJava 运行时环境包含 JVM 和 Java 核心类库。JDK 是 Java Development KitJava 开发工具包包含 JRE还额外包含编译器 javac、诊断工具 jstack、jmap、jstat、可视化工具 JConsole 等。简单说JDK 是给开发者用的JRE 是给运行 Java 程序的人用的JVM 是真正执行字节码的那一层。面试里很容易变形问法比如“一个只需要运行 Java 程序的服务器应该装 JDK 还是 JRE”“为什么生产环境直接用 JDK 而不是精简 JRE”。前者答案明确后者要结合实际情况很多中间件、Agent 工具、动态编译场景会用到 JDK 自带工具所以生产环境装完整 JDK 更省事。不过 Oracle JDK 和 OpenJDK 在发行版上有授权和更新策略差别这块要以实际使用的版本和公司规定为准。1.2 JVM 内存模型和 Java 内存模型 JMM 是两回事这是高频混淆点。JVM 内存模型指的是运行时数据区包括堆、虚拟机栈、本地方法栈、方法区HotSpot 里叫元空间 Metaspace和程序计数器。JMM 是 Java Memory ModelJava 内存模型它定义的是多线程场景下共享变量的可见性、有序性和原子性规则核心是 happens-before 原则和主内存、工作内存的交互。面试时如果只把 JVM 内存模型和 JMM 混在一起说会被认为概念不清晰。正确答法是JVM 内存模型回答“对象存在哪、线程栈在哪、元空间在哪”JMM 回答“多线程读写共享变量时一个线程的修改什么时候对另一个线程可见”。1.3 初始启动参数里最常用的几个堆内存配置不管面试还是调优堆内存参数都绕不开。常见配置如下-Xms堆初始大小一般和-Xmx设成一样避免运行时扩容引起抖动。-Xmx堆最大大小。-Xmn年轻代大小。-XX:MetaspaceSize元空间初始大小。-XX:MaxMetaspaceSize元空间最大大小。-XX:HeapDumpOnOutOfMemoryErrorOOM 时自动导出堆快照。-XX:HeapDumpPath堆快照输出路径。-XX:CompileThreshold方法调用多少次后触发 JIT 编译这是一个容易被忽略的参数。之前看过一个线上问题服务在启动后频繁卡顿日志里没有明显异常后来用 jstat 看编译状态才发现-XX:CompileThreshold被调得很低方法调用次数很容易触发 JIT 编译导致 CPU 飙升。这种参数平时不会被注意到但面试官如果问起“JIT 和解释执行你怎么调优”它就是一个得分点。2. 运行时数据区内存模型里的每一步都对应参数2.1 堆、栈、方法区的真实分工运行时数据区是 JVM 面试的第一道主菜。要理解它不能只背名字得知道每个区域存什么什么情况下报错。程序计数器占内存很小记录当前线程执行的字节码行号线程私有不会 OOM。虚拟机栈描述 Java 方法执行的内存模型每次方法调用创建一个栈帧栈帧里有局部变量表、操作数栈、动态链接、方法返回地址。栈深度超过限制抛 StackOverflowError栈扩展申请不到内存抛 OutOfMemoryError。本地方法栈服务于 native 方法HotSpot 把本地方法栈和虚拟机栈合在一起。堆是所有线程共享的区域存放对象实例GC 的主要回收区域。方法区在 JDK 8 之后被元空间替代存放类元信息、静态变量、常量池等默认使用本地内存。回答时要能说出关键变化JDK 8 之后字符串常量池移到了堆永久代没有了类元数据放到元空间。2.2 对象创建过程和高频面试题“对象怎么分配”对象创建流程通常是类加载检查 → 分配内存 → 初始化零值 → 设置对象头 → 执行构造方法。内存分配方式有指针碰撞和空闲列表两种取决于堆是否规整CMS 使用空闲列表Serial、Parallel 等使用指针碰撞。并发环境下分配内存要有同步手段CAS 加失败重试或本地线程分配缓冲 TLAB。大对象直接进入老年代可以通过-XX:PretenureSizeThreshold设置阈值。长期存活的对象达到-XX:MaxTenuringThreshold指定年龄后进入老年代。动态年龄判定则是 Survivor 中同年龄对象大小总和超过 Survivor 空间一半时大于等于该年龄的对象直接进入老年代。面试官经常追问为什么大对象直接进老年代因为大对象在年轻代里复制成本高来回在 Eden 和 Survivor 之间拷贝容易触发 Minor GC直接放到老年代更省事。但又要注意如果对象本身是短期大对象直接进老年代会加速 Full GC。2.3 从参数看堆分区Eden、Survivor、老年代年轻代默认由 Eden 加两个 Survivor 组成比例通常通过-XX:SurvivorRatio控制默认 8:1:1。但不要盲目相信默认值需要实际验证因为不同 JVM 版本和 GC 策略下可能不同。Minor GC 发生在年轻代Major GC 清理老年代Full GC 一般指回收整个堆和方法区。这里有一个常见误解Major GC 和 Full GC 经常被混用但 Full GC 通常会伴随 STW 且停顿更长。G1 出现后又有了 Young GC、Mixed GC、Full GC 三种动作必须按收集器分开讲。3. GC 和 STW从判定垃圾到一次完整回收3.1 引用计数和可达性分析怎么选判断对象是否可回收最常考的是可达性分析算法。从 GC Roots 出发沿着引用链往下找能被找到的对象就是存活对象找不到的就是垃圾。GC Roots 包括虚拟机栈中引用的对象、静态属性引用的对象、常量引用的对象、本地方法栈中 native 方法引用的对象以及处于同步锁中的对象等。引用计数算法因为无法解决循环引用问题主流 JVM 不用它。比如对象 A 引用了 BB 又引用了 A两个对象都被外部断开后引用计数仍不为零就永远不会被回收。引用类型也是必考项强引用、软引用、弱引用、虚引用。软引用在内存不足时回收适合做缓存弱引用每次 GC 都会被回收虚引用主要用来跟踪对象回收状态比如堆外内存的回收通知。3.2 年轻代到老年代的晋升链路一次对象回收过程可以这样描述对象先分配在 Eden 区Eden 满时触发 Minor GC。Minor GC 采用复制算法把存活对象复制到 Survivor 区同时年龄加 1。对象在 Survivor 区里每经过一次 Minor GC 年龄加 1默认到 15 岁进入老年代。Survivor 不够时会通过分配担保直接进入老年代。需要记住年龄阈值可以通过-XX:MaxTenuringThreshold调整但动态年龄判定优先。如果 Survivor 里同年龄对象总大小超过一半就提前晋升不一定非得等到 15 岁。3.3 STW 到底是什么能不能完全消除STWStop The World指的是 GC 发生时JVM 必须暂停所有业务线程让 GC 线程执行回收。为什么必须暂停因为如果业务线程继续修改对象引用可达性分析会一直处于变化状态无法确定哪些对象是真正可回收的。STW 不是越短越好但也不是越长越好关键是业务能否接受。CMS 和 G1 都在压缩 STWZGC 的目标是把停顿控制在毫秒级甚至更低。但所谓“并发”只是把一部分标记、清理动作和业务线程并发执行最终停顿还是存在只是停顿范围变小了。线上有印象很深的案例某接口平时 50ms 返回一天内偶尔出现 2 到 3 秒的尖峰查日志发现每次尖峰都伴随 Full GC。后来发现是缓存对象在高峰期集中过期老年代被大量一次性对象塞满频繁触发 Full GC。处理办法是拆大缓存、错开过期时间、适当调大堆内存并切到 G1。这类问题就是“STW 导致接口卡顿”的典型。3.4 GC Overhead Limit Exceeded 到底指什么热搜词里有一条java.lang.OutOfMemoryError: GC overhead limit exceeded这是线上非常常见的 OOM 类型。意思是 GC 一直在执行但回收效果太差JVM 担心继续跑下去只是空转于是在 GC 时间占比超过 98% 且回收不到 2% 堆内存时直接抛出 OOM。遇到这个错误不要先去加堆内存而是先导出堆快照分析对象占用。常见原因有代码里存在大量临时对象循环创建、缓存未设置过期时间、内存泄漏导致老年代不断增长、批处理任务一次性加载太多数据。排查顺序是先看堆快照再查大对象和线程堆栈最后定位到具体方法和接口。4. CMS、G1、ZGC大厂面试如何对比收集器4.1 CMS 为什么被称为“并发收集但也会 STW”CMSConcurrent Mark Sweep目标是减少停顿。它分为初始标记、并发标记、重新标记、并发清除四个阶段。初始标记需要 STW但只标记 GC Roots 直接引用的对象很快并发标记和业务线程并发执行重新标记需要 STW用于修正并发标记期间业务线程修改的引用并发清除回收垃圾对象。CMS 的缺点很明显使用标记清除算法会产生内存碎片并发阶段占用 CPU不能处理浮动垃圾可能触发 Concurrent Mode Failure 然后退化为 Serial Old 的 Full GC。面试官问到 CMS通常希望你提到碎片问题和退化风险而不只是背四个阶段。4.2 G1 如何把堆切成 RegionG1 把堆划分为多个大小相等的 Region 区域每个 Region 可以是年轻代、老年代或者大对象区逻辑上不再要求物理连续。G1 的回收过程包含 Young GC 和 Mixed GC。Young GC 回收年轻代 RegionMixed GC 同时回收部分老年代 Region目标是控制停顿时间。G1 通过-XX:MaxGCPauseMillis参数指定期望停顿时间默认 200ms 左右。但要注意这只是一个软目标不是硬保证。G1 会优先回收垃圾最多的 Region这就是所谓的 Garbage First 策略既控制停顿又能提升回收效率。大厂面试考察 G1 时喜欢问“什么场景下选 G1 而不是 CMS”。如果堆很大比如 16G 以上且对停顿时间有要求G1 通常更合适。如果堆只有 4G应用本身对停顿不敏感继续用默认收集器也未必有问题。关键是结合堆大小、停顿诉求和 CPU 资源综合判断。4.3 ZGC 为什么能把 STW 压到毫秒级ZGC 是 JDK 11 引入的实验性收集器JDK 15 开始正式支持。它把停顿时间控制在极低水平核心手段是染色指针和读屏障。ZGC 的标记、转移阶段大部分和业务线程并发执行GC 线程通过读屏障处理对象访问引用减少业务线程停顿。ZGC 也有代价它更依赖内存带宽CPU 占用比 G1 高而且对大堆场景更友好。小堆场景用 ZGC 不一定会比 G1 好因为并发处理本身有额外开销。面试被问到 ZGC可以说“低停顿、适合大堆和追求响应延迟的互联网服务但需要额外评估 CPU 成本和兼容性”。4.4 三款收集器对比表下面这份表格适合直接记忆但面试时要展开讲原因。收集器回收算法是否并发标记STW 特点适用场景CMS标记清除是初始标记和重新标记需要 STW堆中等大小追求低停顿G1Region 复制是停顿可预测按 Region 回收大堆停顿敏感JDK 8 后期版本常用ZGC染色指针 读屏障是停顿极短毫秒级超大堆极低延迟要求需要特别说明CMS 在 JDK 9 开始废弃JDK 14 被移除。现在很多老项目还在用 JDK 8所以 CMS 依然会被面试官问但真正新项目已经不太可能选它了。G1 从 JDK 9 开始是默认收集器JDK 8 环境下需要显式开启。5. Arthas 实战线上 JVM 问题不能全靠猜5.1 Arthas 是什么怎么下载和启动Arthas 是阿里巴巴开源的一款 Java 在线诊断工具不需要重启服务就能查看类加载、方法调用、参数值、异常、线程状态和 CPU 占用。它特别适合处理“本地复现不了只能线上看”的问题。Arthas 下载可以直接去 GitHub Releases 拿arthas-boot.jar日常用法是java -jar arthas-boot.jar启动后会出现一个进程列表输入对应序号就可以 attach 到目标 Java 进程。如果机器上只有一个 Java 进程通常直接连接。需要注意Arthas 需要和目标进程有相同用户权限普通用户 attach 其他用户的进程可能失败。5.2 Arthas 启动时无法获取 jps 进程怎么办热搜里有一条“arthas 启动无法获取 jps 进程”这个很常见。原因通常是当前用户看不到目标进程或者目标进程不在当前用户会话下又或者 JDK 的 jps 和实际运行环境不一致。排查顺序是先用jps -l看看能不能列出进程如果 jps 都看不到确认 JAVA_HOME 和 PATH 是否配置正确进程是不是跑在 Docker 容器里容器内有没有安装完整 JDK如果 jps 能看到但 Arthas 列不出尝试直接指定 pid使用java -jar arthas-boot.jar pid。还有一种情况是权限问题容器内以 root 跑的 Java 进程外部普通用户 attach 会被拒绝。如果是 Docker 容器部署的 Java 程序需要先进入容器再执行 Arthas或者把 Arthas 提前放到容器镜像里。容器内没有 jps 时可以手动找进程号ps -ef | grep java # 或 cat /proc/进程号/cmdline用jstack抓线程栈也可以但要先确认有权限。5.3 用 dashboard、thread、heapdump 定位线上问题Arthas 里最常用的命令是dashboard它展示当前进程的整体状态CPU 占用、内存、GC 次数、线程数量。执行方式是在 Arthas 交互环境中输入dashboard按q退出。thread命令可以查看所有线程的状态和 CPU 占用。比如thread -n 3这条命令会显示 CPU 占用最高的前三个线程。如果某个线程一直处于 BLOCKED 状态基本能判断存在锁竞争。再加参数thread -b可以找出当前阻塞其他线程的锁这对排查死锁和锁竞争非常有用。堆内存方面Arthas 也提供了heapdump命令可以先执行heapdump /tmp/heap.hprof然后导入 MAT 或 JProfiler 分析。不过我一般建议先用vmmap或jmap导出堆快照Arthas 的heapdump更适合已经进入 Arthas 交互环境后快速导出。5.4 用 trace、watch 跟踪方法调用和 URL 路径热搜词里有一句“Arthas 可以跟踪 url 的调用路径吗”。可以直接说Arthas 不能直接像网关一样从 URL 维度跟踪整个调用链但可以借助trace和watch组合做到方法级链路追踪。思路是先用trace跟踪 Controller 方法的调用路径看每个内部方法的耗时trace com.example.controller.OrderController createOrder如果只关心某个方法的入参和返回值用watch com.example.service.OrderService createOrder {params, returnObj} -x 3如果想知道某个异常在哪个 URL 下被抛出可以 watch 异常watch com.example.service.OrderService createOrder throwExp {params, throwExp} -x 3这种方式可以把“某个 URL 请求”和“具体方法参数、异常、耗时”对应起来前提是你能定位到入口方法。如果项目里用的是 Dubbo配合 Arthas 的trace也能看到 RPC 调用路径。6. 大厂面试原题从 OOM 到高并发调优6.1 GC 频繁发生在哪个区怎么定位面试题常见问法“线上系统 GC 频繁你怎么定位。”回答要有层次先用jstat -gcutil pid 1000看各代 GC 次数和耗时。再用jmap -dump:formatb,file/tmp/heap.hprof pid导出堆快照。用 MAT 分析对象大小查找是大对象、缓存增长还是内存泄漏。同时看线程堆栈确认是不是大量并发请求导致对象激增。如果是 Full GC 频繁重点看老年代占用率是否持续高位。老年代一直不降基本可以怀疑两类问题长期存活对象过多或者存在内存泄漏。前者通过调整堆比例或回收策略后者必须查代码。6.2 亿级电商高并发场景下JVM 怎么优化大厂面试喜欢结合“亿级电商、高并发”来问比如“双十一大促前你会怎么调 JVM”。不要直接说堆越大越好。高并发场景下核心不是堆大小而是减少 GC 停顿和分配压力。常见优化思路有合理设置-Xms和-Xmx避免运行时扩容。根据对象生命周期设置-Xmn让大部分短期对象在年轻代就回收减少老年代被塞满的概率。开启-XX:UseG1GC设置合理的-XX:MaxGCPauseMillis。对缓存类对象设置 TTL防止过期对象长期堆积。高峰期前做压测观察 GC 次数和 STW 时间。避免代码里频繁创建大对象、避免在循环里做字符串拼接、避免用同步锁保护热点短操作。面试官可能追问“为什么高并发下不宜把年轻代调太大”。因为年轻代太大会导致 Minor GC 频率降低但单次 GC 停顿时间变长而且老年代空间被压缩Full GC 风险升高。这需要根据对象存活率动态调整而不是拍脑袋给一个数字。6.3 异常重启后 JVM 日志去哪看热搜词里“异常重启 jvm 日志在哪儿”是一条实战问题出现频率很高。日志要看三类第一类是应用日志包括 logback、log4j2 输出的业务日志路径由应用配置决定。第二类是 GC 日志需要用 JVM 参数显式开启比如-Xlog:gc*:/opt/logs/gc.log:time,uptime,level,tagsJDK 8 的写法是-XX:PrintGCDetails -XX:PrintGCDateStamps -Xloggc:/opt/logs/gc.log第三类是 JVM 错误日志通常由-XX:ErrorFile指定比如-XX:ErrorFile/opt/logs/hs_err_pid%p.log。当 JVM 发生致命错误时这里会记录崩溃原因、线程状态和本地调用栈。容器部署场景要特别留意Docker 容器如果被 OOM Killer 杀掉JVM 本身可能来不及写日志这时要查系统日志或 dmesg确认是不是容器内存超限被内核杀掉了。如果 JVM 只是异常退出先看应用启动脚本确认日志路径和容器挂载目录是否一致。7. 可复用的 JVM 排查清单和相关参数7.1 一个相对稳妥的线上排查顺序我自己排查 JVM 问题时会遵循这个顺序先看现象是服务卡顿、接口超时、进程重启还是 CPU 100%。再看日志应用日志、GC 日志、JVM 错误日志按时间对齐。看资源CPU、内存、磁盘 IO、网络连接数用top、free、df确认。看 JVM 内部jps、jstat、jstack、jmap配合 Arthas dashboard。定位代码根据线程堆栈和方法调用链回到具体业务代码。验证修复小流量、灰度发布、压测对比。这个顺序的核心是先确认问题是不是 JVM 引起的再考虑怎么调参。很多情况下接口慢不是 JVM 的问题而是数据库慢查询、Redis 超时、网络延迟。7.2 常见参数记录表建议把常用的 JVM 参数整理成一份模板每次上线前检查一遍。参数含义建议-Xms堆初始大小和 -Xmx 保持一致-Xmx堆最大大小根据容器内存预留-Xmn年轻代大小结合对象存活率设置-XX:MetaspaceSize元空间初始大小避免动态扩容-XX:MaxMetaspaceSize元空间最大大小防止类加载泄漏-XX:UseG1GC使用 G1 收集器JDK 9 之后默认-XX:MaxGCPauseMillisG1 期望停顿时间默认 200ms-XX:HeapDumpOnOutOfMemoryErrorOOM 时导出堆快照生产环境必开-Xlog:gc开启 GC 日志不同版本语法不同-XX:CompileThresholdJIT 编译阈值不轻易修改7.3 一些容易踩的坑先说 GC 日志版本问题。JDK 8 的 GC 日志参数和 JDK 11 以后不一样。JDK 8 常用-XX:PrintGCDetailsJDK 11 以后推荐-Xlog:gc*。如果你在更新 JDK 版本后没有同步改参数会看到“Unrecognized VM option”之类的报错服务根本起不来。再说不建议直接修改-XX:CompileThreshold。这个参数控制方法调用多少次后触发 JIT 编译改小了会让 JIT 更早介入可能提升峰值性能但也会增加编译线程压力。生产环境没有明确依据时保持默认即可。最后是 Arthas 的权限问题。线上生产环境使用 Arthas必须走审批流程注意账号权限和审计。attach 进程时不要随意使用 root避免诊断过程引入新的风险。如果是容器环境记得确认容器内有没有/proc权限这是 Arthas 获取进程信息的关键。7.4 学习路线建议准备 JVM 面试不必一开始就盯着 ZGC 源码先把基础链路打通类加载机制 → 运行时数据区 → 对象分配 → GC 算法 → 收集器对比 → STW 影响 → 线上诊断工具 → 项目实战调优。源码对比可以作为加分项。比如 G1 的 Region 划分、ZGC 的染色指针理解原理后面试官问到“ZGC 相对 G1 的改动点”你就能说清楚。但如果基础概念还不牢先不要强啃源码。大厂面试更看重的是你能不能把问题讲成一条完整闭环而不是零散记忆。项目实战部分是拉开差距的关键。如果你做过高并发项目可以准备一个真实案例系统之前用 CMS每天大促时 Full GC 频繁通过调整堆内存、切换 G1、优化缓存和对象创建把 Full GC 次数降到多少接口 99 分位耗时下降多少。这里的数字要真实没数据就不要编面试官追问细节很容易露馅。我现在给大多数人的建议是把内存模型、GC、STW、Arthas 这四个点串成一条排错主线再准备一两个自己经手或复现过的真实案例。刷题只能帮你过第一轮真正决定面试深度的是你对线上问题的判断力和调优思路。