先聊一个很多朋友问过我的问题学了这么久的Java天天跟JVM打交道但它到底是什么面试的时候被问JVM内存模型、垃圾回收器、调优工具总感觉答不全面。这篇文章我打算用一篇讲透的力度把JVM从内存模型、类加载、垃圾回收到调优实战、面试考点全部串起来大家看完能建立起一个完整的知识框架出去面试或者排查线上问题心里至少有个谱。这个内容适合谁准备面试的Java工程师必然要看工作三五年但没系统梳理过JVM的也建议读一遍哪怕是初学者只要Java基础语法过关跟着我的思路走下来也能理解七八成。我会尽量用大白话加真实案例来讲不整那些教科书式的干巴巴理论毕竟JVM这东西理解原理和会动手排查是两码事。1. 先聊清楚JVM到底是什么1.1 一个Java程序从源码到运行的完整链路很多人第一次接触JVM的时候脑子里只有一个模糊的概念Java虚拟机”再问细一点就说不清了。实际上JVM的全称是Java Virtual Machine它是一台用软件模拟出来的计算机专门用来执行Java字节码。我们从一段源码说起。你写了一个Hello.java文件第一步用javac把它编译成Hello.class这个class文件里装的不是机器码而是字节码bytecode。字节码是JVM的指令集跟CPU的指令集是两回事。然后你执行java HelloJVM启动把class文件加载进来逐条解释或者编译执行这些字节码。这就是一次编译到处运行背后的真相不同的操作系统上有不同版本的JVM但只要你生成的是标准字节码每个平台上的JVM都能读懂并执行。所以Java跨平台的本质是把适配各种操作系统这件事外包给了JVM开发者只负责产出统一的字节码。这里我想强调一个容易混淆的概念JVM不等于Java。JVM只是一个字节码执行规范理论上任何语言只要能编译成符合规范的字节码都能跑在JVM上比如Scala、Kotlin、Groovy甚至有人把Python解释器跑在JVM上。所以你在学习JVM时学的其实是一套通用的运行时技术某种意义上比Java语言本身更底层、更值钱。1.2 从整体架构看JVM的三大子系统JVM内部可以粗略分成三大块类加载子系统、运行时数据区、执行引擎。类加载子系统负责把class文件加载到内存做验证、准备、解析这些动作运行时数据区就是我们常说的内存模型堆、栈、方法区都在这一层执行引擎负责真正执行字节码包括解释器、JIT编译器、垃圾回收器。这三块的关系打个比方类加载子系统像是原料采购和处理部门把农产品class文件做成净菜Class对象运行时数据区是库房和操作台放着净菜和半成品执行引擎是炒菜的师傅把净菜做成成品菜同时还要负责厨房清洁——垃圾回收器就是那个随时收拾台面的清洁工。这个整体认知非常重要因为后续我们讲的所有细节都逃不出这三个子系统的范畴。面试的时候如果被问到你对JVM的理解先抛出这个架构框架再逐个展开远比零散地背几个概念要显得扎实。2. 运行时数据区JVM内存到底怎么划分的2.1 五块内存分区逐一说清JVM规范把运行时数据区分成五个区域其中有三个是线程私有的两个是线程共享的。别小看这个划分它是理解并发和内存安全的起点。先说线程私有的三块。第一是程序计数器它很小记录当前线程正在执行的字节码指令地址。因为线程切换后需要恢复到之前执行的位置所以每个线程都得有自己的计数器。注意它不会发生内存溢出。第二是虚拟机栈每个线程在创建时会分配一个栈栈里面存的是栈帧。每次调用一个方法就往栈里压入一个栈帧方法执行完栈帧弹出。一个栈帧里包含局部变量表、操作数栈、动态链接、方法出口等信息。如果递归调用太深就会抛StackOverflowError这就是栈溢出。第三是本地方法栈它服务的是native方法。很多底层操作比如IO读写、网络通信最终都会调用到操作系统层面的native方法这些方法执行时使用本地方法栈。再说线程共享的两块这就是重头戏了。堆是JVM管理的内存中最大的一块几乎所有对象实例都在这里分配。方法区存的是类元信息、常量、静态变量等JDK8之后被改造成元空间Metaspace实现。这两块是垃圾回收的主战场后面我会重点展开。2.2 堆内存结构与JDK8后的元空间堆内存不是一整块铁板JVM在设计时把它分成了新生代和老年代新生代里面又细分成Eden区、Survivor From区和Survivor To区比例默认是8:1:1。为什么要分这么多块为了配合分代垃圾回收算法让不同年龄的对象用不同的回收策略这个逻辑放到垃圾回收部分解释。对象一般先在Eden区分配经过一轮Minor GC还存活的对象会被移到Survivor区每扛过一轮GC年龄加一年龄达到阈值默认15就会被晋升到老年代。JDK8之后方法区的实现从永久代换成了元空间这是一个很多人忽略但面试必考的变化。永久代在JDK8被彻底移除取而代之的是元空间元空间使用的不是JVM堆内存而是本地内存直接内存。这么改的动机很简单永久代的内存上限很难调常常因为加载的类太多导致java.lang.OutOfMemoryError: PermGen space而元空间默认只受本地内存大小限制出现OOM的概率大幅降低。我在这块踩过一个坑当年给一个老项目排查OOM日志里清清楚楚写着PermGen space但那台机器的Java版本是JDK8不存在永久代。后来发现是一个很老的项目用JDK7在跑部署脚本里还写着-XX:PermSize参数。所以排查内存问题第一件事就是确认JDK版本别拿着旧知识套新环境。2.3 对象从出生到回收的完整过程理解了内存分区我们再走一遍对象的完整生命周期这段是JVM面试的必问题目。当你在代码里写new Object()JVM会先做类加载检查这个类是否已经被加载、验证、准备、初始化过如果没有先触发类加载。接着为对象分配内存分配方式有指针碰撞和空闲列表两种取决于堆内存是否规整而是否规整又取决于垃圾回收器用的是标记-整理还是标记-清除算法。分配内存时还要考虑并发安全默认用CAS加失败重试的方式来保证线程安全。内存分配完之后JVM会把对象头、实例数据、对齐填充三部分都初始化好。之后是构造函数执行也就是你在字节码里看到的invokespecial 方法。注意分配内存和初始化是两回事JVM先用默认零值初始化内存再执行构造函数。对象用完之后要等某个时刻垃圾回收器发现它不可达才会被回收。一个对象生死攸关的判断依赖的是可达性分析算法这个我放在垃圾回收部分讲。整条链路走下来你会发现对象的创建看似简单背后牵扯的细节非常多。3. 类加载机制你真的了解双亲委派吗3.1 类加载的五个阶段加载、验证、准备、解析、初始化class文件不是一上来就能用的JVM加载一个类要经过五个阶段。加载阶段通过类的全限定名获取二进制字节流把字节流转化成方法区里的运行时数据结构并在堆中生成一个Class对象作为访问入口。验证阶段是把关的检查字节流是否符合Class文件规范防止恶意或不完整代码引入。准备阶段给类的静态变量分配内存并设置初始值注意这里用的是默认值比如static int会被设成0真正赋值要等到初始化阶段。解析阶段是把常量池里的符号引用替换成直接引用也就是把类名、方法名这些字面量解析成真正可以指向内存地址的引用。初始化阶段才是真正执行类构造函数 的时候给静态变量赋值、执行静态代码块都发生在这。有个经典考点子类初始化时会先初始化父类吗答案是不一定只有子类真正用到父类的静态字段、静态方法或构造器时父类才会先初始化。如果只是声明了子类引用但没实例化父类不会初始化。3.2 双亲委派模型为什么要让父加载器先加载JVM里类加载器有层级关系顶层是启动类加载器Bootstrap ClassLoader它负责加载JDK核心类库比如rt.jar里的那些第二层是扩展类加载器Extension ClassLoaderJDK8之后改叫Platform ClassLoader负责加载一些扩展库第三层是应用程序类加载器App ClassLoader负责加载classpath下的类。双亲委派模型的核心规则是一个类加载器收到加载请求后先不自己动手而是把请求委派给父加载器逐级向上直到启动类加载器父加载器加载不了才往下回传到子加载器尝试。为什么要这么设计最直接的原因是安全。比如你写了一个类叫java.lang.String如果系统加载器不先委派给最顶层的Bootstrap ClassLoader去加载真正的String那么你的项目里就能随意定义核心库类把整个JDK的类替换掉后果不堪设想。双亲委派保证了一个类在JVM里永远由同一个加载器加载核心类库不会被用户自定义类污染。3.3 打破双亲委派的真实场景双亲委派不是铁律有几种场景必须打破它。最典型的是Tomcat每个Web应用需要独立的类库版本同一个类名在不同应用里可能不同如果严格走双亲委派后加载的类就会覆盖先加载的应用之间就互相污染了。所以Tomcat自己实现了WebAppClassLoader先加载Web应用自己的类再委派给父加载器。另一个经典场景是SPI机制比如JDBC。DriverManager是启动类加载器加载的但它要调用MySQL的驱动实现这个实现类在classpath下启动类加载器根本加载不到。于是JVM引入了线程上下文类加载器让更高层级的类加载器反向去加载低层级的类。面试被问到如何打破双亲委派时一定要能说出这几种场景和原理。光背结论没用要能解释为什么需要打破、打破之后怎么保证安全。我见过很多候选人只停留在重写loadClass方法的层面但问一句为什么要重写就答不出来了。4. 垃圾回收JVM最核心的设计4.1 对象存活判定引用计数与可达性分析垃圾回收器要回收对象首先得知道哪些对象该死。引用计数法是最朴素的思路对象被引用一次就加1引用失效就减1计数为0就回收。听起来很合理但它解决不了一个致命问题——循环引用。A引用了BB引用了A外部没有引用它们但它们的计数永远不为0就永远不被回收内存就泄漏了。所以主流JVM用的是可达性分析算法。它的思路是从一系列根对象GC Roots出发沿着引用链向下遍历能被遍历到的对象叫可达遍历不到的就是可回收对象。GC Roots包括虚拟机栈中引用的对象、方法区中静态属性引用的对象、常量引用的对象、本地方法栈中JNI引用的对象等。这个算法还有个连带考点就是Java的四种引用类型。强引用是最常见的只要还有强引用存在对象就永远不会被回收软引用在内存不足时会被回收适合做缓存弱引用只要垃圾回收一发生就会被回收虚引用最特殊它根本不能用来获取对象只用于在对象被回收时收到一个系统通知。4.2 基础回收算法标记-清除、复制、标记-整理可达性分析找到了该死的对象接下来用什么姿势回收经典算法有三个。标记-清除算法分两步先标记要回收的对象然后统一清除。缺点是会产生大量内存碎片空间碎片太多后面分配大对象时可能找不到连续空间。复制算法把内存分成两块只使用一块回收时把存活对象复制到另一块然后一次性清空原来那块。优点是不会产生碎片缺点是可用的内存直接少了一半。新生代里Eden:Survivor8:1的这个比例就是为了配合复制算法设计的实际只浪费一个Survivor区10%80%的Eden里的对象大部分是朝生夕死的复制成本很低。标记-整理算法是针对老年代的标记存活对象之后让所有存活对象向一端移动然后直接清理掉边界以外的内存。这样既避免了碎片又不需要浪费一半内存。现代JVM的垃圾回收不是单独用一种算法而是分代配合新生代用复制算法老年代用标记-整理或标记-清除这就是分代收集理论。4.3 主流垃圾收集器从Serial到ZGCSerial是最古老的单线程收集器GC时会暂停所有业务线程Stop The World现在已经很少单独使用。Parallel是Serial的多线程版本JDK8默认的收集器组合就是Parallel Scavenge Parallel Old它的目标是提高吞吐量适合后台计算任务。CMS是第一款真正意义上的并发收集器它追求最短回收停顿时间适合响应优先的应用。但CMS有两个著名问题一是并发阶段会占用CPU资源可能拖慢业务线程二是它采用的标记-清除算法会产生内存碎片而且老年代内存碎片严重时可能会导致Full GC提前发生甚至在JDK8以前的版本有严重的并发模式失败问题。CMS在JDK9被标记废弃JDK14被正式移除但市面上还有大量老项目在用它所以面试依然会问。G1是当前很多JDK8项目的首选它把堆划分成很多大小相同的Region块不再严格区分新生代老年代的物理地址而是用Region的逻辑来分配。G1可以预测停顿时间通过-XX:MaxGCPauseMillis参数来软控制。它适合大堆比如堆内存4G以上。从JDK9开始G1成为默认收集器。ZGC是JDK11引入的实验性质收集器配合JDK16转正它的最大亮点是停顿时间几乎不随堆大小增长号称暂停时间不超过10ms。ZGC使用了染色指针、读屏障等黑科技适合超大堆和低延迟场景但配置比较复杂。对于生产环境如果还没上JDK17并且对延迟要求极高ZGC值得一试。选收集器没有银弹我的建议是JDK8默认Parallel的组合不需要乱动除非你明确知道自己的瓶颈是停顿时间有低延迟要求就评估G1特别是堆超过4G时如果堆几十个G而且能接受上新版本JDK那ZGC值得考虑。4.4 看懂GC日志和常见回收器参数排查GC问题第一步是看懂GC日志。用-XX:PrintGCDetails开启详细日志之后你会看到类似这样的输出[GC (Allocation Failure) [PSYoungGen: 1280K-128K(1536K)] 5120K-4096K(5632K), 0.0012345 secs] [Times: user0.00 sys0.00, real0.00 secs]这里面信息量很大PSYoungGen是新生代回收器1280K是回收前占用128K是回收后占用括号里是总容量后面5120K是堆回收前占用4096K是堆回收后占用最后是耗时。看到频繁的Young GC且回收前后内存下降不明显说明新生代里存活对象多可能有短期对象没及时死掉看到Full GC频繁说明老年代快满了要么是对象晋升太快要么是内存泄漏要么是堆配置太小。GC相关核心参数我也列一下大家配置时对照着看参数作用-Xms / -Xmx初始堆大小 / 最大堆大小建议两值相等-Xmn新生代大小-XX:NewRatio老年代与新生代比例默认2-XX:SurvivorRatioEden与Survivor比例默认8-XX:MaxTenuringThreshold晋升老年代的年龄阈值默认15-XX:PrintGCDetails打印GC详细日志-XX:PrintGCDateStamps打印GC时间戳注意-Xmx直接设成物理内存的几分之一没有统一公式要结合业务对象大小、并发量、机器上其他进程占用一起考虑。生产环境我一般建议先给到机器物理内存的50%-70%再用压测验证。5. JVM调优实战工具、参数与排查思路5.1 命令行工具四件套jps、jstat、jmap、jstackJVM调优和排查问题最基础的就是JDK自带的命令行工具这些工具线上都有不用额外安装遇到问题随手就能用。jps用来查Java进程类似Linux的ps命令。jps -l可以显示完整主类名和进程号很多同学不知道进程号在哪其实第一步就是jps拿到PID。jstat是监控JVM运行时信息的利器重点看垃圾回收和类加载情况。jstat -gc pid 1000每秒打印一次GC信息可以看到Eden区、Survivor区、老年代的使用率以及YGC、FGC次数和耗时。如果YGC特别频繁比如每秒好几次说明新生代太小或者Eden区对象创建太快。jmap是用来dump堆快照的。jmap -heap pid看堆配置和当前使用情况jmap -dump:formatb,fileheap.hprof pid生成堆转储文件后续用MAT或者VisualVM分析。注意jmap dump会暂停JVM生产环境要谨慎最好在低峰期操作。jstack用来打印线程快照排查线程死锁、线程卡死特别有用。jstack pid输出所有线程的栈信息如果发现大量线程处于BLOCKED或WAITING状态结合代码流程基本能定位问题。5.2 图形化和在线诊断工具JConsole、VisualVM、Arthas图形化工具里JConsole和VisualVM都属于看一眼就知道大概情况的工具。JConsole可以实时查看堆内存、线程、类加载、CPU情况特别适合在开发环境观察一个简单应用的运行时表现。VisualVM功能更强能装插件可以分析堆dump文件和线程dump也是排查OOM的好帮手。生产环境我更推荐Arthas这是阿里开源的一款在线诊断工具不修改代码、不需要重启服务就能做很多事。最常用的几个命令dashboard看全局状态thread查看线程jad反编译线上类trace跟踪方法调用耗时。特别提一下sc和watch可以查看类的加载信息、观察方法入参返回值和异常线上排查问题利器。我记得有一次线上接口突然变慢但是日志里看不出异常用Arthas的trace命令跟踪那个接口调用的各个方法发现耗时全集中在一次Redis调用上顺着查下去发现是Redis连接池被耗尽了。这种问题如果没有Arthas这种在线工具只能加日志、发版本、等复现非常痛苦。5.3 核心调优参数解析与参考配置调优不是背参数而是理解参数背后的权衡。我先把几个关键参数讲透。-Xms和-Xmx必须设置为相同的值这样JVM启动时就把堆内存申请到位避免运行期频繁扩容缩容。这不仅是性能优化也是规避线上故障的手段。-XX:HeapDumpOnOutOfMemoryError一定要在生产环境开启当发生OOM时自动生成堆转储文件这是排查内存问题最直接的证据。配合-XX:HeapDumpPath指定路径有时候一个堆dump就能直击问题根源。-XX:UseG1GC开启G1收集器。如果你还在用JDK8但堆比较大可以考虑。-XX:MaxMetaspaceSize给元空间设个上限。虽然元空间用的是本地内存但如果不限制类加载器泄漏会导致本地内存耗尽直接搞挂整个操作系统。这是个隐藏很深的坑。线程栈大小-XX:ThreadStackSize默认是1M如果线程数很多这部分内存占用不容小觑。但是不要随便调小太小会导致栈溢出先确认业务确实需要那么多线程再动。最后给一个比较常见的参考配置模板java -Xms4g -Xmx4g \ -XX:UseG1GC \ -XX:MaxGCPauseMillis200 \ -XX:HeapDumpOnOutOfMemoryError \ -XX:HeapDumpPath/data/logs/ \ -XX:MaxMetaspaceSize512m \ -jar app.jar这个配置适合大部分中等规模的后端服务。注意这只是起步模板真正的调优一定要结合压测结果反复调整。5.4 一次OOM排查的真实过程纸上谈兵没意思我分享一次线上OOM排查的完整过程大家感受一下思路。现象是服务运行两三天后开始频繁Full GC接口响应越来越慢最后直接挂掉查看日志发现OutOfMemoryError: Java heap space。第一反应是看GC情况登录机器执行jstat -gc pid 1000 5发现老年代占用持续攀升Full GC次数快速增加且回收后内存下降不明显。这基本能判断是内存泄漏不是堆配置太小。下一步是拿到堆dump。用jmap -dump:formatb,fileheap.hprof pid注意这是在线dump会暂停JVM当时在凌晨低峰期操作。dump完成之后用MAT打开分析支配树Dominator Tree很快就定位到有一个HashMap占了堆内存的80%以上。顺藤摸瓜查代码发现一个缓存Map只有put没有remove和过期机制key是不断变化的订单号日积月累Map无限膨胀最终把堆撑爆。修复方案很简单换成带有过期策略的本地缓存组件或者在写入时控制大小。过程回顾下来最关键的一步是及时拿到堆dump没有堆dump就只能瞎猜。所以再次强调生产环境务必开启-XX:HeapDumpOnOutOfMemoryError这是你排查OOM的第一手犯罪现场。6. 面试高频考点与避坑清单6.1 高频JVM面试题与回答思路面试这块我按出现频率整理了几个问题大家可以对照自测。JVM内存模型是怎样的这题要展开讲五块区域、线程私有与共享之分最好配合JDK8元空间的变化一起答最后再补一句堆是GC主战场进一步分新生代老年代完整度和深度就拉开了。对象什么时候会被垃圾回收先答可达性分析算法再解释GC Roots的定义然后提到四种引用类型对回收时机的影响。加分项是补一句即使对象被标记为可回收也不一定会立刻被回收至少还需要经历两次标记过程这个细节很多人不知道。G1和CMS有什么区别从三方面答内存布局不同CMS是物理分代G1是Region逻辑分代停顿控制不同CMS无法精确控制停顿时间G1通过-XX:MaxGCPauseMillis做软目标碎片问题不同CMS标记-清除有碎片G1基于Region复制基本没有碎片。什么是双亲委派模型回答时一定要层次清晰先说类加载器的层级再说委派规则重点解释为什么这样设计最后补充哪些场景会打破委派。只背结论不解释原因面试官一眼就能看出来。线上系统怎么排查CPU飙高这是问工具的经典题。思路是top找到高CPU进程再用top -H -p找高CPU线程拿到线程号转成16进制执行jstack pid | grep -A10 nid看线程在干什么。这一整套操作下来面试官会觉得你是真的处理过线上问题。6.2 日常开发中那些不起眼的坑调优工具只是手段真正考验人的是经验。我在日常开发和Code Review中见到的JVM相关坑比纯粹的性能瓶颈多得多。第一个坑是全局静态集合类存数据不清理。像static Map、static List很多人图方便把业务数据直接塞进去又没有任何清理机制。这类问题在测试环境几乎发现不了因为数据量小一上线跑个把月OOM就来了。第二个坑是ThreadLocal使用后不remove。ThreadLocal里的值是绑定在线程上的线程池里的线程不销毁ThreadLocal的值就一直在。用完不remove轻则内存泄漏重则线程复用的时候读到了别人的数据。这是个并发正确性问题不只是内存问题。第三个坑是大对象直接进入老年代。比如一个查询接口返回了很大的List一次性加载几万个对象如果超过-XX:PretenureSizeThreshold设定值会直接进老年代。老年代被大对象塞满Minor GC救不了只能Full GC。这类问题往往表现为运行一段时间后突然GC卡顿其实根因是写代码时候没控制好对象大小。第四个坑非常隐蔽就是日志框架引起的类加载器泄漏。很多框架会缓存类加载器在应用热部署或者动态加载类频繁的场景下老类加载器没被释放导致同一个类被加载了几万次Metaspace爆炸。这类问题排查起来最痛苦因为堆内存看着很正常。碰到Metaspace OOM优先查是不是有类加载器泄漏。6.3 学习JVM的路线建议和几点感想最后聊点学习方法。我个人的建议是先建立整体框架再逐块深入最后一定要实战。第一步把运行时数据区彻底搞明白因为所有关于内存的问题都围绕它展开。第二步理解类加载机制这决定了你对Class和类加载器这两个概念的理解深度。第三步啃垃圾回收这块硬骨头从算法到收集器再到看GC日志。第四步学工具先命令行四件套再Arthas最后是MAT/VisualVM。每一步都去找对应的线上案例或者自己写测试代码去触发问题。动手非常关键你可以在本地自己写一段内存泄漏代码把堆调小跑起来看GC日志然后用jmap抓dump用MAT分析完整走一遍排查流程。这个过程只要做两次你对JVM的理解就会比看十本书都深刻。根据我个人经验JVM知识最大的作用不是让你在面试时多答几道题而是当线上出问题的时候你不会两眼一抹黑。不管是频繁GC、OOM、CPU飙高还是接口变慢底层原因大概率都能在JVM这个层面找到答案。把这套东西吃透你对Java这门语言的掌控感会完全不一样。