尧图网站建设 
1. 先说结论JVM速记到底在记什么JVM速记这套东西其实是过去几年我反复整理、反复修正的一份Java知识骨架。它不追求把每个原理讲成万字的论文而是把你在面试、排查问题、做调优时真正绕不开的那些点压成一套能快速调取的心智模型。很多人学JVM最大的痛点不是资料少而是知识点太散内存模型、垃圾回收、类加载、参数调优、线上排错每个方向都能单独写一本书但实际用起来又互相纠缠。这套速记要解决的就是把这个纠缠解开让你脑子里的JVM从背过但记不住变成理解了就忘不掉。先说清楚这份内容适合谁。如果你是准备Java后端面试的开发它帮你把最高频的考点串成主线如果你是在跑生产环境时偶尔碰到堆溢出、GC停顿、启动参数报错这些诡异问题它能告诉你先从哪儿下手如果你只是刚开始学Java想知道JVM到底是什么、为什么值钱这份速记也不会让你一头扎进源码而是先用最直白的方式把运行机制讲明白。总之这是一份能直接抄作业的速记手册不是教科书。1.1 为什么JVM基础这么难记说句大实话JVM难记的根本原因是它太抽象了。你写的是Java代码眼睛看到的是class文件但代码真正跑起来的时候对象在哪儿分配、什么时候被回收、类是什么时候加载进来的这些全部发生在内存里你看不见也摸不着。人脑对看不见的东西天然不擅长记忆所以很多人背了一堆概念转头就忘。我的解决办法是给JVM建立一个虚拟计算机的类比。你可以把JVM想象成一台专门运行Java字节码的电脑内存模型就是这台电脑的存储结构垃圾回收器就是它的自动保洁系统类加载机制就是它的硬盘读取流程JIT编译器就是它的加速引擎。这样一想JVM就不再是一堆陌生的术语而是一台有结构的机器每个部件各司其职。后面所有章节的内容都是在给这台虚拟电脑的每个部件做细节说明。1.2 速记的正确姿势先画地图再记细节JVM的知识体系虽然大但主线其实只有三条运行时数据区内存长什么样、垃圾回收内存怎么管理、类加载代码怎么进来。我强烈建议你先画一张JVM整体结构的地图不需要多精确只要把几个核心区域的位置和关系标出来比如线程私有的程序计数器、虚拟机栈、本地方法栈线程共享的堆、方法区然后在这张地图上不断补充细节。为什么要先画地图因为JVM里所有知识点都是相互关联的。比如你理解了堆的分代结构才能真正看懂垃圾回收器为什么这么设计理解了类加载的双亲委派才能明白为什么你写的类不会覆盖JDK核心类理解了栈帧结构才知道栈溢出和堆溢出根本不是一回事。这套速记的顺序就是按照这张地图展开的你顺着读一遍相当于把这台虚拟电脑从里到外装了一次。1.3 这份速记覆盖的范围这套速记聚焦在几个最实际的方向JVM内存模型和运行时数据区、垃圾回收算法与回收器的选择、类加载机制与双亲委派、高频面试问答、常见报错的排查思路。每部分都以能直接用为目标该给的参数给参数该给的命令给命令该给的代码给代码。另外要提醒一点JVM本身在持续演进不同版本的内存布局和默认回收器是有差异的。这份速记以JDK 8和JDK 17这两个目前生产环境最常用的版本为主线遇到差异点我会单独说明。如果你用的版本更老或者更新原理层面的内容依然成立具体参数名和默认值就要以官方文档为准了。2. JVM内存模型速记运行时数据区就是一张内存地图2.1 线程私有的三块区域程序计数器、虚拟机栈、本地方法栈JVM的运行时数据区可以按线程是否私有分成两部分。线程私有的区域有三个程序计数器、虚拟机栈、本地方法栈。这些区域随线程生而生、随线程灭而灭不需要垃圾回收器参与管理。程序计数器是当前线程所执行字节码的行号指示器。为什么需要这个东西因为线程的调度是时分复用的一个线程随时可能被挂起又恢复恢复之后必须知道刚才执行到哪儿了所以每个线程必须有一个独立的程序计数器。它的内存占用非常小而且Java规范规定它是唯一一个不会抛出OutOfMemoryError的区域因为它的生命周期和线程绑定线程没了它也就没了。虚拟机栈是真正和Java方法执行强相关的区域。每次调用一个Java方法JVM都会创建一个栈帧里面存着局部变量表、操作数栈、动态链接、方法出口这些信息。方法开始执行就入栈方法结束就出栈所以栈帧的入栈出栈天然对应了方法的调用和返回。这个区域主要有两种异常线程请求的栈深度超过虚拟机允许的深度抛StackOverflowError如果动态扩展时无法申请到足够的内存抛OutOfMemoryError。栈的大小可以用 -Xss 参数调整比如 -Xss512k 表示单个线程栈512KB。本地方法栈和虚拟机栈的作用非常相似区别在于虚拟机栈服务于Java方法本地方法栈服务于native方法。在HotSpot虚拟机里这两块区域实际上被合并在一起了但概念上仍然区分开。面试时如果被问到你只需要把虚拟机栈管Java方法本地方法栈管native方法这个对应关系说出来就够。2.2 线程共享的两块区域堆和方法区堆是JVM内存管理中最大的一块区域也是垃圾回收的主战场。所有线程共享堆所有对象实例和数组几乎都在这里分配内存。堆在物理上不要求连续只要逻辑连续就好而且可以按可扩展方式实现初始内存和最大内存分别用 -Xms 和 -Xmx 控制。日常最常听到的OutOfMemoryError: Java heap space就是因为堆空间不够分配新对象导致的。从垃圾回收的角度堆会做更细的分代划分典型结构是新生代和老年代。新生代又分成Eden区和两个Survivor区通常叫S0和S1比例默认是8:1:1可以通过 -XX:SurvivorRatio 调整。为什么要搞出Eden和Survivor因为大部分对象都是朝生夕死的把它们集中放在新生代用复制算法回收效率最高活得够久的对象晋升到老年代用标记-整理或者标记-清除算法处理避免复制大量存活对象。方法区是另一块线程共享的区域存储已被虚拟机加载的类型信息、常量、静态变量、即时编译器编译后的代码缓存等。在JDK 8之前方法区的实现叫永久代也就是PermGen经常出现 java.lang.OutOfMemoryError: PermGen spaceJDK 8开始永久代被移除方法区改由元空间实现也就是Metaspace默认情况下元空间使用本地内存只受可用物理内存限制可以用 -XX:MaxMetaspaceSize 控制上限。这里的重点是理解方法区是一个规范概念永久代/元空间是不同版本的实现方式。2.3 对象创建到内存分配的完整流程一个普通的Java对象从 new 指令开始到真正可以被使用中间要经过好几个环节面试官非常喜欢在这个链条上做文章。完整流程是类加载检查、分配内存、初始化零值、设置对象头、执行构造方法。第一步JVM遇到 new 指令时先去常量池定位到这个类的符号引用检查这个类是否已经被加载、解析、初始化过没有的话先触发类加载。第二步是给对象分配内存分配方式取决于堆是否规整如果GC之后堆是规整的用指针碰撞只移动一个分界指针如果堆不规整用空闲列表维护一个记录可用内存块的列表。第三步JVM把分配到的内存空间初始化为零值这就保证了对象实例字段在不赋值时也有默认值比如int默认0、boolean默认false。第四步设置对象头包括对象的哈希码、GC分代年龄、锁状态标志、类型指针等。第五步执行init方法也就是构造器里的初始化逻辑到这一步对象才算真正被构造完成。多线程并发分配内存时JVM有一个很精巧的优化叫TLABThread Local Allocation Buffer也就是每个线程在Eden区预分配一块私有缓冲区线程在TLAB内分配对象就不需要加锁同步。只有TLAB用完需要重新申请时才对分配动作加锁。这也是为什么大量小对象并发创建时JVM性能依然不错的原因之一。2.4 内存溢出分类与速记口诀实际工作中最怕的就是内存溢出但不同区域的内存溢出表现完全不同。这里给出一份速记清单遇到问题可以先对照分类排查。Java堆溢出是最常见的表现形式是java.lang.OutOfMemoryError: Java heap space原因通常是对象太多、单个对象太大、或者有对象被GlobalRoot引用无法回收。方法区/元空间溢出的提示是java.lang.OutOfMemoryError: Metaspace常见原因是动态生成大量类或者用了CGLib等字节码增强框架。还有 java.lang.OutOfMemoryError: GC overhead limit exceeded意思是GC回收效率太低比如连续多次GC后仍回收不到2%的内存JVM为了防止死循环式GC主动抛出的异常。另外创建线程时如果无法分配本地内存会抛 java.lang.OutOfMemoryError: unable to create native thread这往往不是堆的问题而是操作系统层面线程数或内存不够了。提示排查OOM时第一步不是看代码而是先确认是哪个区域的内存溢出。拿GC overhead limit exceeded举例如果一上来就加 -Xmx很可能会帮倒忙因为问题往往是存在大量不可回收对象堆一旦调大Full GC反而更频繁停机时间更长。3. 垃圾回收机制速记对象生死判定与回收算法3.1 对象存活判定可达性分析算法垃圾回收的第一步是判断哪些对象已经死去可以被回收。市面上最直观的思路是引用计数法给每个对象加一个引用计数器被引用一次加一引用失效减一计数器为0就回收。但这种方法有个致命缺陷无法解决循环引用问题。两个对象互相引用但已经和GC根节点断开了计数器永远不为0就永远无法回收。所以主流JVM都不采用引用计数法而是用可达性分析算法。可达性分析算法的思路非常像从一个根节点做图的遍历。JVM把一系列称为GC Roots的对象当成起点从这些起点往下搜索引用链任何不在引用链上的对象都判定为可回收。哪些对象能当GC Roots主要有这么几类虚拟机栈栈帧中的局部变量表中引用的对象、方法区中静态属性引用的对象、方法区中常量引用的对象、本地方法栈中JNI引用的对象、被同步锁持有的对象以及JVM内部的引用比如基本类型对应的Class对象、常驻的异常对象、系统类加载器等。还有一个必须掌握的知识点是引用类型的分级。强引用、软引用、弱引用、虚引用它们的强度依次递减。强引用就是日常Object obj new Object()这种只要强引用还在对象永远不会被回收软引用在内存不足时会被回收适合做缓存弱引用只要发生GC就会被回收ThreadLocal的key就是典型用法虚引用唯一目的就是对象被回收时收到一个系统通知它不会决定对象生命周期只用来做对象回收跟踪。面试问到WeakHashMap和HashMap有什么区别ThreadLocal为什么会有内存泄漏底层全是这套引用类型知识。3.2 垃圾回收算法标记清除、标记复制、标记整理垃圾回收算法是理解回收器的基础主流算法就三种另外还有个分代收集策略把它们组合起来用。标记-清除算法分两步先标记出所有需要回收的对象然后统一回收。最大问题是产生大量不连续的内存碎片碎片太多会导致以后分配大对象时无法找到连续空间被迫提前触发一次Full GC。标记-复制算法把内存分成大小相等的两块每次只用一块这块用完就把还存活的对象复制到另一块再一次性清理原来的空间。优点是实现简单、运行高效、不会碎片化缺点是可用内存缩小了一半而且对象存活率高时复制成本很高。标记-整理算法则是先标记存活对象然后把所有存活对象向一端移动再清理掉边界以外的内存解决了碎片问题但移动对象的代价较大。知道了这三种算法的优缺点再看JVM为什么用分代收集就顺理成章了。新生代对象存活率低适合用复制算法所以Eden和Survivor之间靠复制来回收只需要浪费很少的Survivor空间老年代对象存活率高、没有额外空间做分配担保所以用标记-清除或者标记-整理算法。另外不管是哪种算法Stop The World都是绕不开的代价——GC发生时除了垃圾回收器的线程之外所有工作线程都会被暂停。暂停时间越短业务感知越小这也就是为什么G1、ZGC这类追求低延迟的回收器会成为主流。3.3 主流垃圾收集器速查表垃圾收集器是垃圾回收算法的工程实现。JDK 8及以前常见的组合是Parallel CMS或者Parallel Parallel OldJDK 9之后CMS被废弃JDK 17开始默认收集器变成了G1。下面这张表把主流收集器的核心特点压出来面试时直接对照使用。收集器适用区域核心算法特点与使用场景Serial新生代标记-复制单线程简单高效适合客户端模式或堆很小的场景ParNew新生代标记-复制Serial的多线程版本配合CMS使用服务端常用Parallel Scavenge新生代标记-复制关注吞吐量适合后台计算、批量任务Serial Old老年代标记-整理Serial的老年代版本兼容老客户端Parallel Old老年代标记-整理配合Parallel Scavenge追求高吞吐CMS老年代标记-清除并发收集低停顿但对CPU资源敏感有碎片问题JDK9起废弃G1全堆跨区域标记-整理将堆划分为Region可预测停顿JDK9默认适合大堆、低延迟ZGC全堆并发标记-整理/着色指针JDK11引入JDK15转正停顿时间极短适合超大堆、超低延迟这张表的记忆逻辑很简单先把新生代吃复制、老年代吃整理这个规律记死然后记住不同收集器就是在这两个大方向上加多线程、加并发、加区域化。G1和ZGC之所以强本质上是把整体STW扫描堆改成了分区域、可并发地收集把停顿时间从分钟级压到了毫秒级甚至亚毫秒级。3.4 内存分配与回收策略速记对象从创建到进入老年代有一套固定的策略这部分在面试里经常被当成场景题来问。对象优先在Eden区分配。新生代Eden区空间不够时触发一次Minor GC。大对象直接进入老年代因为大对象在新生代需要大量内存移动Eden和Survivor之间频繁复制代价太高所以可以通过 -XX:PretenureSizeThreshold 设置阈值超过阈值的对象直接在老年代分配具体单位是字节。长期存活的对象进入老年代每个对象在对象头里有一个分代年龄字段每熬过一次Minor GC年龄加一当年龄达到 -XX:MaxTenuringThreshold 设定的阈值默认15就晋升到老年代。除了这两条硬性规则还有动态年龄判定和空间分配担保。动态年龄判定意思是如果Survivor区中相同年龄对象的大小总和超过Survivor空间的一半那么年龄大于等于这些对象的对象直接进入老年代不必等到阈值15。空间分配担保的意思是发生Minor GC之前JVM会检查老年代最大可用连续空间是否大于新生代所有对象总空间不够的话就改为一次Full GC。这些策略背后的统一原因就是一句话尽量降低Full GC频率因为Full GC会造成全堆扫描停顿时间比Minor GC大一个量级。4. 类加载机制速记双亲委派模型是安全底线4.1 类加载的七个阶段速记一个类从被加载到被卸载要经历七个阶段加载、验证、准备、解析、初始化、使用、卸载。面试最常考的是加载、验证、准备、初始化和解析这五步的职责划分。加载阶段要完成三件事通过类的全限定名获取定义此类的二进制字节流把字节流所代表的静态存储结构转化为方法区的运行时数据结构在堆中生成一个代表这个类的Class对象作为访问入口。验证阶段是必经的安全校验确保字节流符合JVM规范不会危害JVM自身安全。准备阶段是正式为静态变量分配内存并设置初始值比如static int a 100在准备阶段a的值是0而不是100真正的赋值动作要到初始化阶段才执行。解析阶段把常量池内的符号引用替换为直接引用。初始化阶段才真正执行类构造器方法也就是执行静态变量赋值和静态代码块的逻辑。关于初始化时机有一个重要考点什么情况会触发类的初始化主动引用有六种包括new对象或访问静态字段、调用静态方法、反射调用类、初始化一个类的子类、被当作JVM启动入口的类、JDK 7起的动态语言支持。反过来什么情况不会触发初始化访问父类的静态字段不会初始化子类、定义类数组不会初始化类、引用类的常量不会初始化类。这两条正反规则几乎每年面试都会变着花样考。4.2 双亲委派模型为什么必须从上往下加载双亲委派模型是类加载机制的灵魂。JDK默认有三个层级的类加载器启动类加载器Bootstrap ClassLoader负责加载Java核心库比如lib目录下的rt.jar平台类加载器Platform ClassLoaderJDK 9以前叫扩展类加载器Extension ClassLoader负责加载一些扩展库应用类加载器App ClassLoader负责加载项目classpath下的类。三者的关系不是继承而是组合App的父加载器是PlatformPlatform的父加载器是Bootstrap。双亲委派的工作流程是当一个类加载器收到类加载请求时它不会自己先加载而是先把请求委派给父加载器每一层都是如此所以类加载请求最终会走到Bootstrap只有当父加载器反馈自己无法完成加载时子加载器才自己尝试加载。这样做的核心好处有两个第一避免类重复加载一个类在JVM中只会被同一个类加载器加载一次父加载器加载过的类子加载器不会重复加载第二保护核心类库的安全性比如你写了一个java.lang.String按双亲委派模型它会向上委派给Bootstrap最终加载的是JDK自带的String你的String永远没有机会干扰系统运行。那什么场景会打破双亲委派最典型的是SPI机制比如JDBC驱动。DriverManager在启动类加载器里但它需要加载classpath下的具体驱动实现类这就必须让线程上下文类加载器去加载而这个线程上下文类加载器通常是App ClassLoader这样就反向突破了双亲委派。Tomcat这类Web容器也会打破双亲委派因为每个Web应用应该可以拥有自己独立的类库版本不能互相影响所以Tomcat的WebAppClassLoader优先加载自己应用目录下的类加载不到才交给父加载器。4.3 手写一个自定义类加载器其实很简单自定义类加载器的核心方法其实就一个findClass。你只需要继承ClassLoader覆盖findClass方法在方法里从指定路径读取字节码然后调用defineClass把字节数组转换成Class对象。下面是一个最简实现public class FileClassLoader extends ClassLoader { private String path; public FileClassLoader(String path) { this.path path; } Override protected Class? findClass(String name) throws ClassNotFoundException { String fileName name.replace(., /) .class; String filePath path / fileName; try (FileInputStream in new FileInputStream(filePath)) { byte[] bytes in.readAllBytes(); return defineClass(name, bytes, 0, bytes.length); } catch (Exception e) { throw new ClassNotFoundException(name, e); } } }这里要注意的是findClass和loadClass的区别。loadClass是ClassLoader的入口方法它默认实现双亲委派逻辑findClass是loadClass在父加载器无法加载时才会回调的钩子方法。所以自定义类加载器只需要重写findClass不要重写loadClass否则就把双亲委派模型破坏了。如果你想打破双亲委派那才需要重写loadClass但绝大多数业务场景都用不到。写完之后测试也很简单new一个FileClassLoader调用loadClass然后通过反射创建实例即可。5. JVM面试高频问题速查与实战问答5.1 面试官必问的10个JVM问题JVM面试题翻来覆去其实就那么几类我把最高频的10个问题整理成速查形式每个问题给一个能直接说出口的答案思路面试前过一遍能顶上不小的底气。JVM内存模型是什么样的答线程私有区程序计数器、虚拟机栈、本地方法栈加上线程共享区堆、方法区/元空间再补一句JDK8把永久代换成元空间就完整了。为什么需要GC Roots答可达性分析算法需要一组起点只有从这些起点出发能遍历到的对象才算存活。Minor GC和Full GC有什么区别答Minor GC清理新生代频率高、停顿短Full GC清理整个堆和方法区/元空间频率低但停顿很长。什么情况下对象会进入老年代答大对象直接进、年龄达到阈值进、动态年龄判定进、空间分配担保失败导致的Full GC也可能带进去。双亲委派模型是什么答类加载请求先交给父加载器父加载器处理不了再自己加载核心作用是避免重复加载和防止核心库被篡改。哪些情况会触发Full GC答老年代空间不足、元空间不足、System.gc()调用、CMS的concurrent mode failure等。OOM主要有哪些类型答Java heap space、Metaspace、GC overhead limit exceeded、unable to create native thread、Direct buffer memory。对象在内存中是怎么布局的答对象头、实例数据、对齐填充三部分数组对象还要加数组长度。volatile关键字能保证什么答可见性和有序性通过内存屏障实现但不保证原子性。JVM调优一般调什么答先明确目标比如提高吞吐还是降低延迟然后调整堆大小、GC收集器、关键比例参数最后用压测和监控数据验证。这10个问题是基础中的基础但回答时有一个共性技巧不要只背结论尽量把答案落到JVM具体机制上。比如第9题如果能说到volatile读操作前后插入LoadLoad、LoadStore屏障写操作前后插入StoreStore、StoreLoad屏障面试官会觉得你是真的理解了内存模型而不只是背了概念。5.2 高频调优参数速记清单JVM调优参数非常多但日常真的会用到的高频参数其实就二三十个。下面这张表按内存、GC、信息打印、故障快照四个维度做了分类适合直接存下来当速查表。参数分类参数示例含义堆内存-Xms2g -Xmx2g初始堆和最大堆设为一致避免运行时扩容抖动新生代-Xmn1g新生代大小GC频率和吞吐量受此影响较大栈大小-Xss512k每个线程栈大小线程数非常多的场景要调小元空间-XX:MaxMetaspaceSize512m元空间上限防止动态生成类把内存耗尽比例-XX:SurvivorRatio8Eden和Survivor比例默认8:1:1晋升阈值-XX:MaxTenuringThreshold15对象晋升老年代的年龄阈值GC收集器-XX:UseG1GC使用G1JDK9以后默认大对象-XX:PretenureSizeThreshold1m大于该值的对象直接在老年代分配GC日志-Xlog:gc*JDK9的GC日志统一语法JDK8用-XX:PrintGCDetails堆转储-XX:HeapDumpOnOutOfMemoryError -XX:HeapDumpPath/pathOOM时自动生成堆转储文件排障必备类加载日志-verbose:class打印类加载情况排查类冲突用一份比较稳妥的生产环境启动参数可以这样配java -Xms2g -Xmx2g -Xmn1g -Xss512k \ -XX:MaxMetaspaceSize512m \ -XX:UseG1GC \ -XX:MaxGCPauseMillis200 \ -XX:HeapDumpOnOutOfMemoryError \ -XX:HeapDumpPath/data/logs/app.hprof \ -Xlog:gc*:/data/logs/gc.log:time,tags:filecount5,filesize50m \ -jar your-app.jar这里的-XX:MaxGCPauseMillis200是在告诉G1尽量把GC停顿控制在200毫秒以内。注意是尽量G1会在这条目标下去自动调整新生代大小和各区域回收策略但如果你设置的-Xmx太小它也无法兑现这个承诺。所以我一直强调调优参数组合在一起是一个整体不要单独去调某一个值。5.3 JVM问题排查工具速记JDK自带的命令行工具是排查JVM问题最趁手的兵器。记住一个规律这些工具名字基本都带j前缀功能各管一块。jps是基础工具用来查看当前机器上有哪些Java进程以及它们的进程号相当于JVM版ps。jstat用于监视JVM运行时状态最常用的是jstat -gcutil 进程号 时间间隔可以看到Eden、Survivor、Old、Metaspace的使用率以及YGC和FGC的次数和时间。jmap用于生成堆转储快照比如jmap -dump:formatb,fileheap.hprof 进程号还可以用jmap -histo 进程号查看堆中对象实例数和占用内存排行。jstack用于生成线程快照排查线程死锁、线程阻塞、CPU飙升场景非常有用典型操作是先top -Hp找到CPU最高的线程号再jstack导出线程快照把线程号转成十六进制去快照里找对应线程。jinfo用来查看和修改运行中的JVM参数比如jinfo -flags 进程号就能看到启动时生效的所有参数。除了这些内置工具Arthas是比较流行的在线诊断工具一个java -jar arthas-boot.jar就能连上目标进程可以用dashboard看实时状态、用thread定位卡顿线程、用trace追踪方法调用耗时。它的优势是不用重启应用生产环境排查问题特别方便。另外如果是分析堆转储文件推荐用MAT或者VisualVM重点看Dominator Tree也就是支配树能快速找出哪个对象持有大量内存、谁在引用它。6. 常见JVM报错与排查技巧实录6.1 JVM Heap Space is Exhausted 是怎么踩出来的如果你在用Gradle构建项目很可能会碰到这样一条日志Expiring Daemon because JVM heap space is exhausted。意思是Gradle守护进程Daemon的堆内存被耗尽了守护进程会被主动废弃并重启。我第一次看到这个报错时有点懵因为项目本身没多大怎么构建一下堆就爆了其实这是Gradle守护进程的自我保护机制。Gradle启动一个常驻JVM来跑构建任务避免反复拉起JVM的耗时。但如果某个构建任务特别重或者项目依赖非常多守护进程默认的堆大小撑不住它不会一直卡在那里而是选择过期当前守护进程下一次构建时重新启动一个干净的新进程。解决办法很简单在项目根目录的gradle.properties文件里调整JVM参数。org.gradle.jvmargs-Xmx4096m -XX:MaxMetaspaceSize512m顺手把daemon的日志也打开能看到更多细节org.gradle.daemontrue org.gradle.logging.levelinfo调完之后重新构建大部分情况下报错就消失了。踩过几次坑之后我发现这类堆耗尽问题不仅仅是Gradle特有的任何长驻JVM进程都可能遇到。排查思路永远是一样的先确认进程最大堆是多少再确认内存消耗是持续上涨还是短时冲击最后针对性地调-Xmx或者优化代码。6.2 启动参数读不出来多半是路径和编码的锅下面这条报错看起来比较怪cannot collect jvm options caused by: 0: cannot read:d:v作业实训 vjetbrain_。它在IDEA这类IDE里启动项目时偶尔会出现含义是JVM在尝试读取一组配置选项时读取第一个选项就失败了而这个选项指向了一个看起来像路径的字符串d:v作业实训 vjetbrain_。出现这个问题的核心原因通常是配置文件的路径或者内容出了问题。具体来说有几类情况一IDE的vmoptions文件路径里包含中文、空格或特殊字符JVM在解析时对某些字符处理不友好二路径中的冒号和反斜杠在某些转义逻辑下被吃掉了比如Windows路径D:\某个目录如果配置文件里没有正确转义反斜杠可能被当成转义字符处理三实际指向的文件根本不存在或当前用户没有读取权限。像这个报错里的d:v作业实训就非常典型冒号后面直接跟了中文目录名很可能是配置文件写成了非法的路径格式或者IDE在导入配置时解析错了。解决步骤我觉得可以按顺序排查首先打开IDE关心的vmoptions文件检查文件路径是否合法、是否有拼写错误其次把项目或配置文件挪到一个纯英文、无空格、无特殊字符的路径下再次确认文件编码是UTF-8避免中文在GBK和UTF-8之间混乱导致路径内容变成乱码最后如果IDE有自定义JVM参数的地方直接在IDE设置里重新指定一份干净的vmoptions文件通常比手工改配置文件更稳。这个报错的根因很多时候不是JVM本身出了问题而是给JVM传参的那个人传递了它不认识的参数。6.3 排查OOM的完整实战流程很多同学第一次遇到线上OOM时最想知道的是这个错误信息到底告诉了我什么。其实错误信息只是起点真正要搞定OOM必须有一套固定的排查流程。第一步先确保应用在启动时挂了OOM自动转储参数-XX:HeapDumpOnOutOfMemoryError -XX:HeapDumpPath/data/logs/app.hprof。没有这个参数OOM一发生进程就没了现场也全丢了。第二步复现问题压测或者等待真实触发拿到堆转储hprof文件。第三步用MAT打开hprof先看Overview里的History和Biggest Objects然后打开Dominator Tree找占用堆内存最大的对象。第四步顺着这个对象看它的引用链重点找GC Roots路径看它为什么没有被回收。第五步回到代码定位问题。举个实际的例子我之前排查过一个Batch任务OOM的问题堆转储里占内存最大的是一堆byte[]但业务代码里并没有直接创建这么大的byte数组。顺着引用链往下追发现是查询数据时一次性把整张表加载进了内存缓存数据量远超预期最终被静态Map持有无法回收。解决办法是改成分批查询、限流加载并给静态缓存设置容量上限。这个案例的关键不是那堆byte[]本身而是追踪谁持有它。所以排查OOM的本质永远是找到持有大对象的引用链找到这一步问题基本就解决了一半。6.4 心态与方法JVM速记之后还要看什么这套速记写到这里已经覆盖了JVM最核心的知识骨架。但速记终归是速记它能让你快速建立体系却不能替代更深一层的理解。我个人在整理这些内容时的体会是JVM最值得投入时间去研究的不是某个参数怎么调而是它背后的设计权衡为什么用复制算法处理新生代、为什么用可达性分析而不是引用计数、为什么双亲委派能保护核心库、为什么G1要把堆分成Region。理解了这些为什么你就不需要死记硬背那些结论了。如果你还愿意继续深入强烈建议自己动手做几个小实验用java -verbose:class跑一个HelloWorld看看类加载顺序用jmap和jstack观察一个运行中的应用写一段不断new对象的代码触发一次OOM然后亲手分析堆转储文件。这些实验成本都很低但做完之后你对JVM的信任感和掌控感会完全不一样。最后提醒一句JVM官方文档和《深入理解Java虚拟机》永远是最值得反复翻的两份材料速记负责给你框架它们负责给你深度。 JVM速记手册：内存模型、垃圾回收与调优实战
1. 先说结论JVM速记到底在记什么JVM速记这套东西其实是过去几年我反复整理、反复修正的一份Java知识骨架。它不追求把每个原理讲成万字的论文而是把你在面试、排查问题、做调优时真正绕不开的那些点压成一套能快速调取的心智模型。很多人学JVM最大的痛点不是资料少而是知识点太散内存模型、垃圾回收、类加载、参数调优、线上排错每个方向都能单独写一本书但实际用起来又互相纠缠。这套速记要解决的就是把这个纠缠解开让你脑子里的JVM从背过但记不住变成理解了就忘不掉。先说清楚这份内容适合谁。如果你是准备Java后端面试的开发它帮你把最高频的考点串成主线如果你是在跑生产环境时偶尔碰到堆溢出、GC停顿、启动参数报错这些诡异问题它能告诉你先从哪儿下手如果你只是刚开始学Java想知道JVM到底是什么、为什么值钱这份速记也不会让你一头扎进源码而是先用最直白的方式把运行机制讲明白。总之这是一份能直接抄作业的速记手册不是教科书。1.1 为什么JVM基础这么难记说句大实话JVM难记的根本原因是它太抽象了。你写的是Java代码眼睛看到的是class文件但代码真正跑起来的时候对象在哪儿分配、什么时候被回收、类是什么时候加载进来的这些全部发生在内存里你看不见也摸不着。人脑对看不见的东西天然不擅长记忆所以很多人背了一堆概念转头就忘。我的解决办法是给JVM建立一个虚拟计算机的类比。你可以把JVM想象成一台专门运行Java字节码的电脑内存模型就是这台电脑的存储结构垃圾回收器就是它的自动保洁系统类加载机制就是它的硬盘读取流程JIT编译器就是它的加速引擎。这样一想JVM就不再是一堆陌生的术语而是一台有结构的机器每个部件各司其职。后面所有章节的内容都是在给这台虚拟电脑的每个部件做细节说明。1.2 速记的正确姿势先画地图再记细节JVM的知识体系虽然大但主线其实只有三条运行时数据区内存长什么样、垃圾回收内存怎么管理、类加载代码怎么进来。我强烈建议你先画一张JVM整体结构的地图不需要多精确只要把几个核心区域的位置和关系标出来比如线程私有的程序计数器、虚拟机栈、本地方法栈线程共享的堆、方法区然后在这张地图上不断补充细节。为什么要先画地图因为JVM里所有知识点都是相互关联的。比如你理解了堆的分代结构才能真正看懂垃圾回收器为什么这么设计理解了类加载的双亲委派才能明白为什么你写的类不会覆盖JDK核心类理解了栈帧结构才知道栈溢出和堆溢出根本不是一回事。这套速记的顺序就是按照这张地图展开的你顺着读一遍相当于把这台虚拟电脑从里到外装了一次。1.3 这份速记覆盖的范围这套速记聚焦在几个最实际的方向JVM内存模型和运行时数据区、垃圾回收算法与回收器的选择、类加载机制与双亲委派、高频面试问答、常见报错的排查思路。每部分都以能直接用为目标该给的参数给参数该给的命令给命令该给的代码给代码。另外要提醒一点JVM本身在持续演进不同版本的内存布局和默认回收器是有差异的。这份速记以JDK 8和JDK 17这两个目前生产环境最常用的版本为主线遇到差异点我会单独说明。如果你用的版本更老或者更新原理层面的内容依然成立具体参数名和默认值就要以官方文档为准了。2. JVM内存模型速记运行时数据区就是一张内存地图2.1 线程私有的三块区域程序计数器、虚拟机栈、本地方法栈JVM的运行时数据区可以按线程是否私有分成两部分。线程私有的区域有三个程序计数器、虚拟机栈、本地方法栈。这些区域随线程生而生、随线程灭而灭不需要垃圾回收器参与管理。程序计数器是当前线程所执行字节码的行号指示器。为什么需要这个东西因为线程的调度是时分复用的一个线程随时可能被挂起又恢复恢复之后必须知道刚才执行到哪儿了所以每个线程必须有一个独立的程序计数器。它的内存占用非常小而且Java规范规定它是唯一一个不会抛出OutOfMemoryError的区域因为它的生命周期和线程绑定线程没了它也就没了。虚拟机栈是真正和Java方法执行强相关的区域。每次调用一个Java方法JVM都会创建一个栈帧里面存着局部变量表、操作数栈、动态链接、方法出口这些信息。方法开始执行就入栈方法结束就出栈所以栈帧的入栈出栈天然对应了方法的调用和返回。这个区域主要有两种异常线程请求的栈深度超过虚拟机允许的深度抛StackOverflowError如果动态扩展时无法申请到足够的内存抛OutOfMemoryError。栈的大小可以用 -Xss 参数调整比如 -Xss512k 表示单个线程栈512KB。本地方法栈和虚拟机栈的作用非常相似区别在于虚拟机栈服务于Java方法本地方法栈服务于native方法。在HotSpot虚拟机里这两块区域实际上被合并在一起了但概念上仍然区分开。面试时如果被问到你只需要把虚拟机栈管Java方法本地方法栈管native方法这个对应关系说出来就够。2.2 线程共享的两块区域堆和方法区堆是JVM内存管理中最大的一块区域也是垃圾回收的主战场。所有线程共享堆所有对象实例和数组几乎都在这里分配内存。堆在物理上不要求连续只要逻辑连续就好而且可以按可扩展方式实现初始内存和最大内存分别用 -Xms 和 -Xmx 控制。日常最常听到的OutOfMemoryError: Java heap space就是因为堆空间不够分配新对象导致的。从垃圾回收的角度堆会做更细的分代划分典型结构是新生代和老年代。新生代又分成Eden区和两个Survivor区通常叫S0和S1比例默认是8:1:1可以通过 -XX:SurvivorRatio 调整。为什么要搞出Eden和Survivor因为大部分对象都是朝生夕死的把它们集中放在新生代用复制算法回收效率最高活得够久的对象晋升到老年代用标记-整理或者标记-清除算法处理避免复制大量存活对象。方法区是另一块线程共享的区域存储已被虚拟机加载的类型信息、常量、静态变量、即时编译器编译后的代码缓存等。在JDK 8之前方法区的实现叫永久代也就是PermGen经常出现 java.lang.OutOfMemoryError: PermGen spaceJDK 8开始永久代被移除方法区改由元空间实现也就是Metaspace默认情况下元空间使用本地内存只受可用物理内存限制可以用 -XX:MaxMetaspaceSize 控制上限。这里的重点是理解方法区是一个规范概念永久代/元空间是不同版本的实现方式。2.3 对象创建到内存分配的完整流程一个普通的Java对象从 new 指令开始到真正可以被使用中间要经过好几个环节面试官非常喜欢在这个链条上做文章。完整流程是类加载检查、分配内存、初始化零值、设置对象头、执行构造方法。第一步JVM遇到 new 指令时先去常量池定位到这个类的符号引用检查这个类是否已经被加载、解析、初始化过没有的话先触发类加载。第二步是给对象分配内存分配方式取决于堆是否规整如果GC之后堆是规整的用指针碰撞只移动一个分界指针如果堆不规整用空闲列表维护一个记录可用内存块的列表。第三步JVM把分配到的内存空间初始化为零值这就保证了对象实例字段在不赋值时也有默认值比如int默认0、boolean默认false。第四步设置对象头包括对象的哈希码、GC分代年龄、锁状态标志、类型指针等。第五步执行init方法也就是构造器里的初始化逻辑到这一步对象才算真正被构造完成。多线程并发分配内存时JVM有一个很精巧的优化叫TLABThread Local Allocation Buffer也就是每个线程在Eden区预分配一块私有缓冲区线程在TLAB内分配对象就不需要加锁同步。只有TLAB用完需要重新申请时才对分配动作加锁。这也是为什么大量小对象并发创建时JVM性能依然不错的原因之一。2.4 内存溢出分类与速记口诀实际工作中最怕的就是内存溢出但不同区域的内存溢出表现完全不同。这里给出一份速记清单遇到问题可以先对照分类排查。Java堆溢出是最常见的表现形式是java.lang.OutOfMemoryError: Java heap space原因通常是对象太多、单个对象太大、或者有对象被GlobalRoot引用无法回收。方法区/元空间溢出的提示是java.lang.OutOfMemoryError: Metaspace常见原因是动态生成大量类或者用了CGLib等字节码增强框架。还有 java.lang.OutOfMemoryError: GC overhead limit exceeded意思是GC回收效率太低比如连续多次GC后仍回收不到2%的内存JVM为了防止死循环式GC主动抛出的异常。另外创建线程时如果无法分配本地内存会抛 java.lang.OutOfMemoryError: unable to create native thread这往往不是堆的问题而是操作系统层面线程数或内存不够了。提示排查OOM时第一步不是看代码而是先确认是哪个区域的内存溢出。拿GC overhead limit exceeded举例如果一上来就加 -Xmx很可能会帮倒忙因为问题往往是存在大量不可回收对象堆一旦调大Full GC反而更频繁停机时间更长。3. 垃圾回收机制速记对象生死判定与回收算法3.1 对象存活判定可达性分析算法垃圾回收的第一步是判断哪些对象已经死去可以被回收。市面上最直观的思路是引用计数法给每个对象加一个引用计数器被引用一次加一引用失效减一计数器为0就回收。但这种方法有个致命缺陷无法解决循环引用问题。两个对象互相引用但已经和GC根节点断开了计数器永远不为0就永远无法回收。所以主流JVM都不采用引用计数法而是用可达性分析算法。可达性分析算法的思路非常像从一个根节点做图的遍历。JVM把一系列称为GC Roots的对象当成起点从这些起点往下搜索引用链任何不在引用链上的对象都判定为可回收。哪些对象能当GC Roots主要有这么几类虚拟机栈栈帧中的局部变量表中引用的对象、方法区中静态属性引用的对象、方法区中常量引用的对象、本地方法栈中JNI引用的对象、被同步锁持有的对象以及JVM内部的引用比如基本类型对应的Class对象、常驻的异常对象、系统类加载器等。还有一个必须掌握的知识点是引用类型的分级。强引用、软引用、弱引用、虚引用它们的强度依次递减。强引用就是日常Object obj new Object()这种只要强引用还在对象永远不会被回收软引用在内存不足时会被回收适合做缓存弱引用只要发生GC就会被回收ThreadLocal的key就是典型用法虚引用唯一目的就是对象被回收时收到一个系统通知它不会决定对象生命周期只用来做对象回收跟踪。面试问到WeakHashMap和HashMap有什么区别ThreadLocal为什么会有内存泄漏底层全是这套引用类型知识。3.2 垃圾回收算法标记清除、标记复制、标记整理垃圾回收算法是理解回收器的基础主流算法就三种另外还有个分代收集策略把它们组合起来用。标记-清除算法分两步先标记出所有需要回收的对象然后统一回收。最大问题是产生大量不连续的内存碎片碎片太多会导致以后分配大对象时无法找到连续空间被迫提前触发一次Full GC。标记-复制算法把内存分成大小相等的两块每次只用一块这块用完就把还存活的对象复制到另一块再一次性清理原来的空间。优点是实现简单、运行高效、不会碎片化缺点是可用内存缩小了一半而且对象存活率高时复制成本很高。标记-整理算法则是先标记存活对象然后把所有存活对象向一端移动再清理掉边界以外的内存解决了碎片问题但移动对象的代价较大。知道了这三种算法的优缺点再看JVM为什么用分代收集就顺理成章了。新生代对象存活率低适合用复制算法所以Eden和Survivor之间靠复制来回收只需要浪费很少的Survivor空间老年代对象存活率高、没有额外空间做分配担保所以用标记-清除或者标记-整理算法。另外不管是哪种算法Stop The World都是绕不开的代价——GC发生时除了垃圾回收器的线程之外所有工作线程都会被暂停。暂停时间越短业务感知越小这也就是为什么G1、ZGC这类追求低延迟的回收器会成为主流。3.3 主流垃圾收集器速查表垃圾收集器是垃圾回收算法的工程实现。JDK 8及以前常见的组合是Parallel CMS或者Parallel Parallel OldJDK 9之后CMS被废弃JDK 17开始默认收集器变成了G1。下面这张表把主流收集器的核心特点压出来面试时直接对照使用。收集器适用区域核心算法特点与使用场景Serial新生代标记-复制单线程简单高效适合客户端模式或堆很小的场景ParNew新生代标记-复制Serial的多线程版本配合CMS使用服务端常用Parallel Scavenge新生代标记-复制关注吞吐量适合后台计算、批量任务Serial Old老年代标记-整理Serial的老年代版本兼容老客户端Parallel Old老年代标记-整理配合Parallel Scavenge追求高吞吐CMS老年代标记-清除并发收集低停顿但对CPU资源敏感有碎片问题JDK9起废弃G1全堆跨区域标记-整理将堆划分为Region可预测停顿JDK9默认适合大堆、低延迟ZGC全堆并发标记-整理/着色指针JDK11引入JDK15转正停顿时间极短适合超大堆、超低延迟这张表的记忆逻辑很简单先把新生代吃复制、老年代吃整理这个规律记死然后记住不同收集器就是在这两个大方向上加多线程、加并发、加区域化。G1和ZGC之所以强本质上是把整体STW扫描堆改成了分区域、可并发地收集把停顿时间从分钟级压到了毫秒级甚至亚毫秒级。3.4 内存分配与回收策略速记对象从创建到进入老年代有一套固定的策略这部分在面试里经常被当成场景题来问。对象优先在Eden区分配。新生代Eden区空间不够时触发一次Minor GC。大对象直接进入老年代因为大对象在新生代需要大量内存移动Eden和Survivor之间频繁复制代价太高所以可以通过 -XX:PretenureSizeThreshold 设置阈值超过阈值的对象直接在老年代分配具体单位是字节。长期存活的对象进入老年代每个对象在对象头里有一个分代年龄字段每熬过一次Minor GC年龄加一当年龄达到 -XX:MaxTenuringThreshold 设定的阈值默认15就晋升到老年代。除了这两条硬性规则还有动态年龄判定和空间分配担保。动态年龄判定意思是如果Survivor区中相同年龄对象的大小总和超过Survivor空间的一半那么年龄大于等于这些对象的对象直接进入老年代不必等到阈值15。空间分配担保的意思是发生Minor GC之前JVM会检查老年代最大可用连续空间是否大于新生代所有对象总空间不够的话就改为一次Full GC。这些策略背后的统一原因就是一句话尽量降低Full GC频率因为Full GC会造成全堆扫描停顿时间比Minor GC大一个量级。4. 类加载机制速记双亲委派模型是安全底线4.1 类加载的七个阶段速记一个类从被加载到被卸载要经历七个阶段加载、验证、准备、解析、初始化、使用、卸载。面试最常考的是加载、验证、准备、初始化和解析这五步的职责划分。加载阶段要完成三件事通过类的全限定名获取定义此类的二进制字节流把字节流所代表的静态存储结构转化为方法区的运行时数据结构在堆中生成一个代表这个类的Class对象作为访问入口。验证阶段是必经的安全校验确保字节流符合JVM规范不会危害JVM自身安全。准备阶段是正式为静态变量分配内存并设置初始值比如static int a 100在准备阶段a的值是0而不是100真正的赋值动作要到初始化阶段才执行。解析阶段把常量池内的符号引用替换为直接引用。初始化阶段才真正执行类构造器方法也就是执行静态变量赋值和静态代码块的逻辑。关于初始化时机有一个重要考点什么情况会触发类的初始化主动引用有六种包括new对象或访问静态字段、调用静态方法、反射调用类、初始化一个类的子类、被当作JVM启动入口的类、JDK 7起的动态语言支持。反过来什么情况不会触发初始化访问父类的静态字段不会初始化子类、定义类数组不会初始化类、引用类的常量不会初始化类。这两条正反规则几乎每年面试都会变着花样考。4.2 双亲委派模型为什么必须从上往下加载双亲委派模型是类加载机制的灵魂。JDK默认有三个层级的类加载器启动类加载器Bootstrap ClassLoader负责加载Java核心库比如lib目录下的rt.jar平台类加载器Platform ClassLoaderJDK 9以前叫扩展类加载器Extension ClassLoader负责加载一些扩展库应用类加载器App ClassLoader负责加载项目classpath下的类。三者的关系不是继承而是组合App的父加载器是PlatformPlatform的父加载器是Bootstrap。双亲委派的工作流程是当一个类加载器收到类加载请求时它不会自己先加载而是先把请求委派给父加载器每一层都是如此所以类加载请求最终会走到Bootstrap只有当父加载器反馈自己无法完成加载时子加载器才自己尝试加载。这样做的核心好处有两个第一避免类重复加载一个类在JVM中只会被同一个类加载器加载一次父加载器加载过的类子加载器不会重复加载第二保护核心类库的安全性比如你写了一个java.lang.String按双亲委派模型它会向上委派给Bootstrap最终加载的是JDK自带的String你的String永远没有机会干扰系统运行。那什么场景会打破双亲委派最典型的是SPI机制比如JDBC驱动。DriverManager在启动类加载器里但它需要加载classpath下的具体驱动实现类这就必须让线程上下文类加载器去加载而这个线程上下文类加载器通常是App ClassLoader这样就反向突破了双亲委派。Tomcat这类Web容器也会打破双亲委派因为每个Web应用应该可以拥有自己独立的类库版本不能互相影响所以Tomcat的WebAppClassLoader优先加载自己应用目录下的类加载不到才交给父加载器。4.3 手写一个自定义类加载器其实很简单自定义类加载器的核心方法其实就一个findClass。你只需要继承ClassLoader覆盖findClass方法在方法里从指定路径读取字节码然后调用defineClass把字节数组转换成Class对象。下面是一个最简实现public class FileClassLoader extends ClassLoader { private String path; public FileClassLoader(String path) { this.path path; } Override protected Class? findClass(String name) throws ClassNotFoundException { String fileName name.replace(., /) .class; String filePath path / fileName; try (FileInputStream in new FileInputStream(filePath)) { byte[] bytes in.readAllBytes(); return defineClass(name, bytes, 0, bytes.length); } catch (Exception e) { throw new ClassNotFoundException(name, e); } } }这里要注意的是findClass和loadClass的区别。loadClass是ClassLoader的入口方法它默认实现双亲委派逻辑findClass是loadClass在父加载器无法加载时才会回调的钩子方法。所以自定义类加载器只需要重写findClass不要重写loadClass否则就把双亲委派模型破坏了。如果你想打破双亲委派那才需要重写loadClass但绝大多数业务场景都用不到。写完之后测试也很简单new一个FileClassLoader调用loadClass然后通过反射创建实例即可。5. JVM面试高频问题速查与实战问答5.1 面试官必问的10个JVM问题JVM面试题翻来覆去其实就那么几类我把最高频的10个问题整理成速查形式每个问题给一个能直接说出口的答案思路面试前过一遍能顶上不小的底气。JVM内存模型是什么样的答线程私有区程序计数器、虚拟机栈、本地方法栈加上线程共享区堆、方法区/元空间再补一句JDK8把永久代换成元空间就完整了。为什么需要GC Roots答可达性分析算法需要一组起点只有从这些起点出发能遍历到的对象才算存活。Minor GC和Full GC有什么区别答Minor GC清理新生代频率高、停顿短Full GC清理整个堆和方法区/元空间频率低但停顿很长。什么情况下对象会进入老年代答大对象直接进、年龄达到阈值进、动态年龄判定进、空间分配担保失败导致的Full GC也可能带进去。双亲委派模型是什么答类加载请求先交给父加载器父加载器处理不了再自己加载核心作用是避免重复加载和防止核心库被篡改。哪些情况会触发Full GC答老年代空间不足、元空间不足、System.gc()调用、CMS的concurrent mode failure等。OOM主要有哪些类型答Java heap space、Metaspace、GC overhead limit exceeded、unable to create native thread、Direct buffer memory。对象在内存中是怎么布局的答对象头、实例数据、对齐填充三部分数组对象还要加数组长度。volatile关键字能保证什么答可见性和有序性通过内存屏障实现但不保证原子性。JVM调优一般调什么答先明确目标比如提高吞吐还是降低延迟然后调整堆大小、GC收集器、关键比例参数最后用压测和监控数据验证。这10个问题是基础中的基础但回答时有一个共性技巧不要只背结论尽量把答案落到JVM具体机制上。比如第9题如果能说到volatile读操作前后插入LoadLoad、LoadStore屏障写操作前后插入StoreStore、StoreLoad屏障面试官会觉得你是真的理解了内存模型而不只是背了概念。5.2 高频调优参数速记清单JVM调优参数非常多但日常真的会用到的高频参数其实就二三十个。下面这张表按内存、GC、信息打印、故障快照四个维度做了分类适合直接存下来当速查表。参数分类参数示例含义堆内存-Xms2g -Xmx2g初始堆和最大堆设为一致避免运行时扩容抖动新生代-Xmn1g新生代大小GC频率和吞吐量受此影响较大栈大小-Xss512k每个线程栈大小线程数非常多的场景要调小元空间-XX:MaxMetaspaceSize512m元空间上限防止动态生成类把内存耗尽比例-XX:SurvivorRatio8Eden和Survivor比例默认8:1:1晋升阈值-XX:MaxTenuringThreshold15对象晋升老年代的年龄阈值GC收集器-XX:UseG1GC使用G1JDK9以后默认大对象-XX:PretenureSizeThreshold1m大于该值的对象直接在老年代分配GC日志-Xlog:gc*JDK9的GC日志统一语法JDK8用-XX:PrintGCDetails堆转储-XX:HeapDumpOnOutOfMemoryError -XX:HeapDumpPath/pathOOM时自动生成堆转储文件排障必备类加载日志-verbose:class打印类加载情况排查类冲突用一份比较稳妥的生产环境启动参数可以这样配java -Xms2g -Xmx2g -Xmn1g -Xss512k \ -XX:MaxMetaspaceSize512m \ -XX:UseG1GC \ -XX:MaxGCPauseMillis200 \ -XX:HeapDumpOnOutOfMemoryError \ -XX:HeapDumpPath/data/logs/app.hprof \ -Xlog:gc*:/data/logs/gc.log:time,tags:filecount5,filesize50m \ -jar your-app.jar这里的-XX:MaxGCPauseMillis200是在告诉G1尽量把GC停顿控制在200毫秒以内。注意是尽量G1会在这条目标下去自动调整新生代大小和各区域回收策略但如果你设置的-Xmx太小它也无法兑现这个承诺。所以我一直强调调优参数组合在一起是一个整体不要单独去调某一个值。5.3 JVM问题排查工具速记JDK自带的命令行工具是排查JVM问题最趁手的兵器。记住一个规律这些工具名字基本都带j前缀功能各管一块。jps是基础工具用来查看当前机器上有哪些Java进程以及它们的进程号相当于JVM版ps。jstat用于监视JVM运行时状态最常用的是jstat -gcutil 进程号 时间间隔可以看到Eden、Survivor、Old、Metaspace的使用率以及YGC和FGC的次数和时间。jmap用于生成堆转储快照比如jmap -dump:formatb,fileheap.hprof 进程号还可以用jmap -histo 进程号查看堆中对象实例数和占用内存排行。jstack用于生成线程快照排查线程死锁、线程阻塞、CPU飙升场景非常有用典型操作是先top -Hp找到CPU最高的线程号再jstack导出线程快照把线程号转成十六进制去快照里找对应线程。jinfo用来查看和修改运行中的JVM参数比如jinfo -flags 进程号就能看到启动时生效的所有参数。除了这些内置工具Arthas是比较流行的在线诊断工具一个java -jar arthas-boot.jar就能连上目标进程可以用dashboard看实时状态、用thread定位卡顿线程、用trace追踪方法调用耗时。它的优势是不用重启应用生产环境排查问题特别方便。另外如果是分析堆转储文件推荐用MAT或者VisualVM重点看Dominator Tree也就是支配树能快速找出哪个对象持有大量内存、谁在引用它。6. 常见JVM报错与排查技巧实录6.1 JVM Heap Space is Exhausted 是怎么踩出来的如果你在用Gradle构建项目很可能会碰到这样一条日志Expiring Daemon because JVM heap space is exhausted。意思是Gradle守护进程Daemon的堆内存被耗尽了守护进程会被主动废弃并重启。我第一次看到这个报错时有点懵因为项目本身没多大怎么构建一下堆就爆了其实这是Gradle守护进程的自我保护机制。Gradle启动一个常驻JVM来跑构建任务避免反复拉起JVM的耗时。但如果某个构建任务特别重或者项目依赖非常多守护进程默认的堆大小撑不住它不会一直卡在那里而是选择过期当前守护进程下一次构建时重新启动一个干净的新进程。解决办法很简单在项目根目录的gradle.properties文件里调整JVM参数。org.gradle.jvmargs-Xmx4096m -XX:MaxMetaspaceSize512m顺手把daemon的日志也打开能看到更多细节org.gradle.daemontrue org.gradle.logging.levelinfo调完之后重新构建大部分情况下报错就消失了。踩过几次坑之后我发现这类堆耗尽问题不仅仅是Gradle特有的任何长驻JVM进程都可能遇到。排查思路永远是一样的先确认进程最大堆是多少再确认内存消耗是持续上涨还是短时冲击最后针对性地调-Xmx或者优化代码。6.2 启动参数读不出来多半是路径和编码的锅下面这条报错看起来比较怪cannot collect jvm options caused by: 0: cannot read:d:v作业实训 vjetbrain_。它在IDEA这类IDE里启动项目时偶尔会出现含义是JVM在尝试读取一组配置选项时读取第一个选项就失败了而这个选项指向了一个看起来像路径的字符串d:v作业实训 vjetbrain_。出现这个问题的核心原因通常是配置文件的路径或者内容出了问题。具体来说有几类情况一IDE的vmoptions文件路径里包含中文、空格或特殊字符JVM在解析时对某些字符处理不友好二路径中的冒号和反斜杠在某些转义逻辑下被吃掉了比如Windows路径D:\某个目录如果配置文件里没有正确转义反斜杠可能被当成转义字符处理三实际指向的文件根本不存在或当前用户没有读取权限。像这个报错里的d:v作业实训就非常典型冒号后面直接跟了中文目录名很可能是配置文件写成了非法的路径格式或者IDE在导入配置时解析错了。解决步骤我觉得可以按顺序排查首先打开IDE关心的vmoptions文件检查文件路径是否合法、是否有拼写错误其次把项目或配置文件挪到一个纯英文、无空格、无特殊字符的路径下再次确认文件编码是UTF-8避免中文在GBK和UTF-8之间混乱导致路径内容变成乱码最后如果IDE有自定义JVM参数的地方直接在IDE设置里重新指定一份干净的vmoptions文件通常比手工改配置文件更稳。这个报错的根因很多时候不是JVM本身出了问题而是给JVM传参的那个人传递了它不认识的参数。6.3 排查OOM的完整实战流程很多同学第一次遇到线上OOM时最想知道的是这个错误信息到底告诉了我什么。其实错误信息只是起点真正要搞定OOM必须有一套固定的排查流程。第一步先确保应用在启动时挂了OOM自动转储参数-XX:HeapDumpOnOutOfMemoryError -XX:HeapDumpPath/data/logs/app.hprof。没有这个参数OOM一发生进程就没了现场也全丢了。第二步复现问题压测或者等待真实触发拿到堆转储hprof文件。第三步用MAT打开hprof先看Overview里的History和Biggest Objects然后打开Dominator Tree找占用堆内存最大的对象。第四步顺着这个对象看它的引用链重点找GC Roots路径看它为什么没有被回收。第五步回到代码定位问题。举个实际的例子我之前排查过一个Batch任务OOM的问题堆转储里占内存最大的是一堆byte[]但业务代码里并没有直接创建这么大的byte数组。顺着引用链往下追发现是查询数据时一次性把整张表加载进了内存缓存数据量远超预期最终被静态Map持有无法回收。解决办法是改成分批查询、限流加载并给静态缓存设置容量上限。这个案例的关键不是那堆byte[]本身而是追踪谁持有它。所以排查OOM的本质永远是找到持有大对象的引用链找到这一步问题基本就解决了一半。6.4 心态与方法JVM速记之后还要看什么这套速记写到这里已经覆盖了JVM最核心的知识骨架。但速记终归是速记它能让你快速建立体系却不能替代更深一层的理解。我个人在整理这些内容时的体会是JVM最值得投入时间去研究的不是某个参数怎么调而是它背后的设计权衡为什么用复制算法处理新生代、为什么用可达性分析而不是引用计数、为什么双亲委派能保护核心库、为什么G1要把堆分成Region。理解了这些为什么你就不需要死记硬背那些结论了。如果你还愿意继续深入强烈建议自己动手做几个小实验用java -verbose:class跑一个HelloWorld看看类加载顺序用jmap和jstack观察一个运行中的应用写一段不断new对象的代码触发一次OOM然后亲手分析堆转储文件。这些实验成本都很低但做完之后你对JVM的信任感和掌控感会完全不一样。最后提醒一句JVM官方文档和《深入理解Java虚拟机》永远是最值得反复翻的两份材料速记负责给你框架它们负责给你深度。