题目请介绍 JVM 的内存模型、垃圾回收机制以及如何进行 JVM 性能调优。参考答案前言JVM 这道题堪称面试中的瑞士军刀——无论你面的是初级开发还是高级架构它都有可能出现只是追问的深度不同。很多同学背了一堆参数和概念被面试官追问一句你线上调过 JVM 吗就瞬间破功。这篇文章的目标是带你从 JVM 内存布局出发一路讲到 GC 调优实战让你的回答既有理论深度又有落地经验。放心我不会让你背 50 个 JVM 参数。我们只抓重点用最轻松的方式搞定最硬核的知识。一、先看全景——你的 Java 程序跑在怎样的地基上在聊细节之前你得先有一个大局观。JVM 启动后会从操作系统那里申请一大块内存然后把这块内存划分为不同的功能区各司其职。用一句话记住这个布局堆和元空间是公共广场所有人都能逛栈、程序计数器、本地方法栈是私人房间每人一间。二、拆开看——每个区域到底装了什么2.1 程序计数器它是啥一块小小的内存记录当前线程正在执行的字节码行号。人话版就像你看书用的书签。CPU 切来切去每次切回来都得知道上次读到哪了。每个线程有自己独立的书签互不干扰。面试要记住的点它是 JVM 规范中唯一一个不会抛出 OutOfMemoryError的区域。2.2 Java 虚拟机栈它是啥每个方法执行时JVM 都会创建一个栈帧压入虚拟机栈。方法执行完栈帧出栈。栈帧里装着局部变量表、操作数栈、方法返回值等。人话版栈就是你的办公桌。每调用一个方法就在桌上叠一层文件栈帧。方法执行完把最上面那层文件收走。桌上堆太高递归太深桌子塌了——这就是 StackOverflowError。// 经典递归翻车现场没有正确的终止条件栈帧无限叠加 public static void recursiveCall() { recursiveCall(); // 每次调用压一个栈帧最终 StackOverflowError }面试要记住的点栈深度超过 JVM 允许的最大值 →StackOverflowError栈扩容时无法申请到足够内存 →OutOfMemoryError2.3 本地方法栈跟虚拟机栈功能一样只不过它服务的是native 方法用 C/C 写的本地方法。了解即可面试中很少单独问。2.4 堆它是啥存放所有对象实例和数组的地方。是 GC 垃圾回收的主战场也是 JVM 中最大的一块内存。人话版堆就像公司的仓库。new 出来的所有对象都丢进去。仓库管理不善就会又乱又满GC 就是那个定期来清理仓库的管理员。堆的内部还有更细的划分这是理解 GC 的关键为什么叫伊甸园因为绝大部分对象刚 new 出来就夭折了朝生夕死在 Eden 区活不过一次 GC。2.5 方法区 / 元空间它是啥存储类的元数据类名、方法名、字段描述符、静态变量、常量池、JIT 编译后的代码。重要变迁JDK 7 及之前叫永久代PermGen在堆里JDK 8 及之后改成了元空间Metaspace使用系统本地内存不再受堆大小限制。// 元空间 OOM 的经典场景动态生成大量类 // 比如 CGLIB 动态代理、大量 JSP 编译成 Servlet // 解决设置 -XX:MaxMetaspaceSize256m面试考点JDK 8 为什么把永久代干掉换成元空间永久代大小难控制太小容易 OOM太大浪费堆空间永久代的内存回收效率低元空间使用本地内存只受系统内存限制更加灵活三、垃圾回收GC——JVM 面试的灵魂考题3.1 怎么判断对象死了GC 不是随便删东西的它得先搞清楚谁还活着、谁已经死了。方法一引用计数法Java 不用这个给每个对象加个计数器有人引用就 1引用失效就 -1。归零就回收。听起来很美好但它有个致命缺陷——循环引用class Node { Node next; } Node a new Node(); Node b new Node(); a.next b; b.next a; // A 和 B 互相引用 a null; b null; // 俩对象计数器永远 1永远回收不掉方法二可达性分析Java 用的就是这个从一组叫GC Roots的根对象出发顺着引用链一路找下去。能找到的就是活的找不到的就是死的。GC Roots (栈中的引用、静态变量等) │ ┌──────┼──────┐ ▼ ▼ ▼ Object1 Object2 Object3 │ │ ▼ ▼ Object4 Object5 ← 从 GC Roots 到不了它 │ ▼ Object6 ← 能从 GC Roots 到达它是活的哪些是 GC Roots虚拟机栈中引用的对象局部变量静态属性引用的对象常量池引用的对象JNI 引用的对象被synchronized持有的对象3.2 GC 分代回收——一场精心策划的人口清理HotSpot JVM 将堆分为新生代和老年代用不同的策略来回收这就是分代回收理论弱分代假说大部分对象都是朝生夕死的。强分代假说活得越久的对象越不容易死。基于这两个假设JVM 做了这样的设计区域对象特征GC 名称触发时机回收特点新生代朝生夕死Minor GC/ Young GCEden 区满了频繁、速度快老年代活得久Major GC/ Old GC老年代空间不足比 Minor GC 慢很多整个堆混合Full GC老年代/元空间满、System.gc()最慢STWStop The World时间长Minor GC 的完整过程重点这是面试中一定要能讲清楚的过程第 1 步新对象诞生在 Eden 区 ┌─────────────┐ │ Eden区 │ ← 新对象都往这里放 ├──────┬──────┤ │ S0区 │ S1区 │ ← 两个 Survivor 区同一时间只有一个在用 └──────┴──────┘ 第 2 步Eden 区满了触发 Minor GC - 标记 Eden 和当前 Survivor 中存活的对象 - 把活着的对象复制到另一个空的 Survivor 区 - 年龄 1 - 清空 Eden 和刚腾出来的 Survivor 区 第 3 步对象在两个 Survivor 之间来回复制 - 每熬过一次 GC年龄 1 - 年龄超过阈值默认 15参数 -XX:MaxTenuringThreshold 晋升到老年代 第 4 步特殊情况 - 活下来的对象太多Survivor 区放不下 → 直接进老年代空间担保 - 超大对象比如大数组→ 直接进老年代参数 -XX:PretenureSizeThreshold这个过程就像搬家游戏新员工对象进公司试用期Eden 区没过就走了过了一轮考核的搬到骨干区Survivor考核多次都挺过来的晋升为元老老年代。3.3 四种引用类型——软硬皆施各有用处Java 提供了四种引用从强到弱// 1. 强引用Strong Reference——打死我也不放手 Object obj new Object(); // 只要 obj 还指向它GC 绝不回收 // 2. 软引用Soft Reference——内存不够了可以牺牲 SoftReferenceObject softRef new SoftReference(new Object()); // 内存充足时不会被回收内存不足时会被回收 // 典型用途缓存、图片加载 // 3. 弱引用Weak Reference——下次 GC 我就没了 WeakReferenceObject weakRef new WeakReference(new Object()); // 不管内存足不足下一次 GC 必回收 // 典型用途WeakHashMap、ThreadLocal 中的 key // 4. 虚引用Phantom Reference——我就是个通知而已 PhantomReferenceObject phantomRef new PhantomReference(new Object(), queue); // 无法通过虚引用获取对象唯一用途是对象被回收时收到一个系统通知 // 典型用途管理直接内存的回收面试关键词引用类型回收条件典型使用场景强引用绝不回收普通的 new 对象软引用内存不足时才回收本地图片缓存弱引用下次 GC 必回收WeakHashMap、ThreadLocal虚引用跟没有一样只是通知直接内存NIO DirectByteBuffer回收追踪四、垃圾回收器——JVM 的清洁工团队JVM 提供了多种 GC 收集器各有各的适用场景。下图帮助记忆核心收集器新生代收集器 老年代收集器 ┌──────────┐ ┌──────────────┐ │ Serial │ │ Serial Old │ ← 单线程Client 模式默认 ├──────────┤ ├──────────────┤ │ ParNew │ │ CMS │ ← 经典搭配ParNew CMS ├──────────┤ ├──────────────┤ │Parallel │ │Parallel Old │ ← 吞吐量优先经典搭配 │Scavenge │ │ │ └──────────┘ └──────────────┘ ↑ ↑ └───────────┬───────────────┘ │ G1 (Garbage First) ← JDK 9 默认 │ ZGC / Shenandoah ← 超低延迟JDK 114.1 各收集器一句话速记收集器一句话总结Serial单线程干活干的时候所有人停下STW。就像小便利店只有一个收银员顾客少时够用ParNewSerial 的多线程版本。本质上还是全停但清理时多个线程同时干活Parallel Scavenge关注吞吐量干活时间 / 总时间。追求单位时间内完成尽可能多的工作不在乎单次暂停CMS老年代收集器追求最短停顿时间。一边打扫一边营业大部分阶段和应用线程并发执行G1放弃连续分代把堆切成等大的 Region。可预测停顿时间JDK 9 起的默认收集器ZGC超低延迟暂停时间不超过10ms支持 TB 级堆。JDK 11 实验性引入JDK 15 正式版4.2 CMS 的七步成诗与它的致命缺陷CMS 是面试最爱问的老年代收集器因为它设计精巧但问题也不少CMS 工作流程以老年代回收为例 初始标记 并发标记 重新标记 并发清除 (initial mark) (concurrent mark) (remark) (concurrent sweep) │ │ │ │ ▼ ▼ ▼ ▼ STW 与用户线程 STW 与用户线程 短暂暂停 并发执行 短暂暂停 并发执行CMS 的三个致命缺陷对 CPU 资源敏感并发阶段会占用 CPU减少应用吞吐量浮动垃圾并发清除时新产生垃圾只能等下次 GC内存碎片标记-清除算法不整理内存碎片多了会提前触发 Full GC你可以这样记 CMS 的最终下场JDK 14 中 CMS 被正式移除它的继任者 G1 上位了。4.3 G1——现在的当红辣子鸡G1 的设计思路跟传统收集器完全不同传统收集器 G1 收集器 ┌──────────────┐ ┌───┬───┬───┬───┐ │ │ │ E │ S │ O │ H │ ← Region │ 新生代 │ ├───┼───┼───┼───┤ │ │ │ O │ E │ S │ H │ ├──────────────┤ ├───┼───┼───┼───┤ │ │ │ H │ E │ O │ S │ │ 老年代 │ ├───┼───┼───┼───┤ │ │ │ S │ O │ E │ O │ └──────────────┘ └───┴───┴───┴───┘ 连续的内存块 整个堆被切分成等大的 Region EEden, SSurvivor, OOld, HHumongousG1 的核心思想不追求一次清理整个堆而是优先回收垃圾最多的 RegionGarbage First 名字的由来每次只回收一部分 Region把停顿时间控制在用户设定的目标内-XX:MaxGCPauseMillis200。五、JVM 性能调优——从玄学到科学很多人觉得 JVM 调优是门玄学——同样的参数在生产 A 环境好好的到 B 环境就崩了。其实调优是有套路的核心就是六个字监控 → 分析 → 调整。5.1 第一步明确你的目标调优前先问自己三个问题我要的是吞吐量还是低延迟这两个通常是矛盾的内存吃紧吗堆太小频繁 GC堆太大 GC 单次时间太长GC 频率和时间是什么水平需要先监控5.2 第二步用对工具看数据调优最忌讳的就是猜一切要以监控数据为准工具/命令用途一句话说明jps查看 Java 进程 PIDjps -l列出所有 Java 进程jstat实时监控 GC 情况jstat -gc pid 1000每秒输出一次 GC 数据jmap导出堆快照jmap -dump:live,fileheap.hprof pidjstack查看线程堆栈jstack pid排查死锁、线程挂起jinfo查看/修改 JVM 参数jinfo -flag MaxHeapSize pidjvisualvm图形化监控工具JDK 自带JDK 9 需要单独下载Arthas阿里开源诊断工具在线诊断神器不需要重启 JVMMAT分析堆转储文件Eclipse Memory Analyzer分析内存泄漏利器5.3 第三步核心参数速查# 堆内存设置 -Xms2g # 初始堆大小建议和 -Xmx 设一样避免内存抖动 -Xmx2g # 最大堆大小 -Xmn1g # 新生代大小或 -XX:NewRatio2 表示老年代/新生代2:1 # 元空间设置 -XX:MetaspaceSize128m # 元空间初始大小 -XX:MaxMetaspaceSize256m # 元空间最大大小防止无限制增长 # GC 选择 -XX:UseG1GC # 使用 G1 收集器JDK 9 默认 -XX:UseZGC # 使用 ZGCJDK 11超低延迟 # GC 日志 -Xlog:gc*:filegc.log:time,uptime:filecount5,filesize20M # 输出详细 GC 日志到文件滚动保存 5 个每个 20M # OOM 时自动 Dump -XX:HeapDumpOnOutOfMemoryError -XX:HeapDumpPath/path/to/dump # G1 特有参数 -XX:MaxGCPauseMillis200 # G1 期望的最大停顿时间不是硬保证 -XX:G1HeapRegionSize4m # G1 Region 大小1M~32M建议设成 2 的幂5.4 第四步常见问题排查场景一频繁 Full GC现象系统响应越来越慢日志里 Full GC 一个接一个。排查思路jstat -gc pid 1000确认 GC 频率和耗时jmap -dump导出堆快照用 MAT 分析哪些对象占了最多内存常见原因内存泄漏静态集合不断增长、大对象频繁分配、堆太小// 常见的内存泄漏写法 public class MemoryLeak { private static ListObject list new ArrayList(); // 静态集合GC 永远不会回收 public void addData(Object data) { list.add(data); // 数据只增不减迟早 OOM } }场景二CPU 飙升 100%现象CPU 突然飙到 100%应用假死。排查思路top -H -p pid找到 CPU 占用最高的线程printf %x\n tid转成十六进制jstack pid | grep hex_tid定位到代码行场景三OOM 不同死法的含义异常信息含义排查方向java.lang.OutOfMemoryError: Java heap space堆内存不足扩大堆或用 MAT 分析java.lang.OutOfMemoryError: Metaspace元空间不足类加载过多动态代理增大 MaxMetaspaceSizejava.lang.OutOfMemoryError: unable to create new native thread线程数达到上限检查ulimit -u排查线程泄漏java.lang.StackOverflowError栈溢出递归太深或循环依赖java.lang.OutOfMemoryError: Direct buffer memory直接内存不足NIO 使用不当DirectByteBuffer 没有正确释放六、面试高频追问合集Q1什么情况下会发生栈内存溢出递归没有正确的终止条件、栈深度过大如深度递归遍历一棵极深的树。Q2方法区 / 元空间什么时候会 OOM运行时生成了大量的动态类CGLIB 动态代理、大量 JSP、动态语言如 Groovy。这种情况需要限制元空间大小或排查类加载器泄漏。Q3什么是 Stop The WorldGC 线程工作时在某些阶段需要暂停所有用户线程这个暂停就叫 STW。就像清洁工要打扫会议室必须让正在开会的人全部出去。暂停时间直接影响用户体验。G1 和 ZGC 的核心卖点就是STW 时间短。Q4G1 和 CMS 有什么区别CMS 是老年代收集器需要配合 ParNew 或 Serial 处理新生代。G1 是全堆收集器把堆切成 Region可预测停顿时间还自带内存整理不像 CMS 会产生大量碎片。CMS 已经在 JDK 14 被移除了。Q5遇到过 JVM 调优的实际案例吗这是面试官最想听到的实战故事。建议准备一个真实的调优案例比如某接口 RT响应时间突然从 50ms 飙升到 2000ms →jstat发现频繁 Full GC →jmapdump 堆发现某个缓存 Map 无限增长 → 加 LRU 淘汰策略 限制大小 → 搞定。这个模板几乎适用于 80% 的面试场景。七、一句话带走JVM 内存分五块堆、栈、方法区、程序计数器、本地方法栈。堆是主战场分新生代和老年代。GC 用可达性分析判生死Minor GC 清新生代Full GC 清全堆。调优三板斧堆大小、GC 选择、内存泄漏排查。核心原则是——先监控后调参别猜面试回答模板如果你在面试中被问到请介绍 JVM 与性能调优可以参考下面的口语版回答JVM 内存主要分为五大区域堆、虚拟机栈、方法区、程序计数器和本地方法栈。其中堆和方法区是线程共享的栈、程序计数器、本地方法栈是线程私有的。堆里又分为新生代和老年代新生代又细分为 Eden 区和两个 Survivor 区。垃圾回收方面JVM 通过可达性分析来判断对象是否存活从 GC Roots 出发能被引用链到达的对象就是活的否则就是垃圾。GC 分为 Minor GC、Major GC 和 Full GC。Minor GC 发生在新生代非常频繁但速度快Full GC 会覆盖整个堆会触发 Stop The World对性能影响最大。常见的垃圾回收器有 Serial、Parallel、CMS、G1 和 ZGC其中 G1 是现在的主流选择它把堆分成多个大小相等的 Region可以设定期望的最大停顿时间。在性能调优方面我通常会遵循监控、分析、调整三步走。先用 jstat、jstack、jmap 这些工具观察 GC 频率和内存分布必要时导出堆快照用 MAT 分析。常见的问题比如频繁 Full GC大概率是堆设置太小或者存在内存泄漏。调优的核心参数包括堆大小-Xms、-Xmx、GC 选择-XX:UseG1GC、GC 日志输出等。有一点很关键一定是在有监控数据的前提下精准调整而不是凭感觉盲目改参数。另外还有个经验线上启动时最好加上 -XX:HeapDumpOnOutOfMemoryError这样一旦 OOM 能自动保留事故现场方便事后分析。
