JVM 底层彻底理解

JVM 底层彻底理解一、JVM 到底解决了什么问题先理解本质JVM 的本质目标只有三点核心结论二、JVM 整体架构为什么要分这些模块JVM 为什么要分这三层JVM 为什么一定要“拆模块”三、运行时数据区JVM 内存模型JVM 内存只分两大类1. 程序计数器最小但不可或缺2. 虚拟机栈排错最常见3. 本地方法栈补充点4. 堆GC 的主战场5. 方法区 / 元空间类的存储区总结四、对象从创建到回收的完整生命周期1. 对象创建全过程2. 内存分配方式为什么有两种3. 对象创建为什么是线程安全的五、垃圾回收机制GC 底层原理1. 如何判断对象已死2. GC 算法为什么要“组合使用”3. G1 垃圾回收器主流总结六、内存泄漏1. 内存泄漏的本质定义2. 常见泄漏场景的底层原因3. 内存泄漏与 OOM 的关系七、逃逸分析JIT 的核心优化能力1. 什么是逃逸2. JVM 为什么关心“逃逸”3. 三大核心优化1. 栈上分配2. 标量替换优化力度最大3. 锁消除总结八、JVM 调优与问题排查1. 常见 OOM 类型先会分类2. 排查 OOM 的标准流程3. 常用 JVM 排查工具总结九、总结一、JVM 到底解决了什么问题先理解本质在 JVM 出现之前C / C 需要手动管理内存内存泄漏、野指针问题频发且难排查程序强依赖操作系统跨平台成本高这些问题的共同点只有一个复杂、易错、不可控。JVM 的本质目标只有三点一句话先记住隔离、托管、优化。屏蔽底层操作系统差异程序不再直接依赖操作系统而是运行在 JVM 之上实现“一次编写到处运行”。自动内存管理GC对象创建、回收由 JVM 统一管理开发者只关心“是否还在使用”不再和内存细节纠缠。通过运行期优化获得接近原生的性能JVM 会在运行过程中识别热点代码并进行编译优化长期运行下性能接近甚至等同原生程序。核心结论JVM 不是为了“极限快”而是为了稳定、可控、可长期运行。它本质上是一个以空间换安全、以运行期分析换性能的工程系统。二、JVM 整体架构为什么要分这些模块JVM 不是一个黑盒而是一个高度分层、职责清晰的系统ClassLoader → Runtime Data Area → Execution Engine一句话理解这条链路先把类弄进来 → 给数据找地方 → 把代码跑起来JVM 为什么要分这三层因为 JVM 要同时解决三类完全不同的问题加载、存储、执行。类加载器ClassLoader核心职责把 class 文件变成 JVM 能用的 Class 对象负责类的加载、校验、链接、初始化支持按需加载而不是一次性全部加载通过双亲委派机制保证核心类安全一句话记忆类加载器决定“类从哪来、能不能用”高频点为什么需要双亲委派一句话答案防止核心类被篡改保证类加载的安全性和一致性。关键点优先由父加载器加载避免自定义类覆盖java.lang.*保证同一个类在 JVM 中的唯一性自定义 ClassLoader 的典型场景一句话答案隔离、扩展、动态加载。典型场景插件化系统不同插件使用不同依赖热加载 / 热部署应用隔离如 Tomcat、多应用容器运行时数据区Runtime Data Area核心职责给程序运行中的数据分配内存方法区类元数据、常量、静态变量堆对象实例虚拟机栈 / 本地方法栈方法调用、局部变量程序计数器线程执行位置一句话记忆运行时数据区决定“数据放哪、生命周期多长”高频点堆和栈的区别一句话答案堆存对象栈存方法调用。关键点堆线程共享GC 管理对象实例栈线程私有方法栈帧自动回收哪些区域线程私有哪些线程共享一句话答案栈、程序计数器是私有的堆和方法区是共享的。记忆口诀“对象共享调用私有”OOM 和 StackOverflowError 的根源一句话答案OOM 是内存不够SOF 是调用太深。对应关系OOM堆、方法区内存耗尽StackOverflowError递归或方法调用层级过深执行引擎Execution Engine核心职责把字节码真正跑起来解释执行启动快JIT 编译热点代码转为机器码运行期优化内联、逃逸分析、锁消除一句话记忆执行引擎决定“怎么跑、跑得快不快”高频点解释执行 vs JIT一句话答案解释执行启动快JIT 执行快。关键点解释执行逐条解释字节码JIT热点代码编译为机器码什么是热点代码一句话答案被频繁执行、值得编译优化的代码。关键点JVM 通过计数器识别热点才会触发 JIT为什么 Java 能越跑越快一句话答案因为 JVM 会对热点代码持续做运行期优化。核心逻辑先解释执行再 JIT 编译最终稳定在高性能状态JVM 为什么一定要“拆模块”如果不拆会出现三个致命问题类加载和内存强耦合无法支持热加载内存和执行强耦合无法做运行期优化执行逻辑固化JIT、GC 无法演进而拆分之后JVM 获得了三种能力解耦加载、存储、执行互不干扰可扩展ClassLoader、GC、JIT 都可替换运行期优化边跑边分析动态决策一句话总结ClassLoader 负责“引入”Runtime Data Area 负责“承载”Execution Engine 负责“执行”JVM 的所有高级特性GC、JIT、热加载都建立在这三层解耦之上。三、运行时数据区JVM 内存模型JVM 的运行时数据区不是随便划的它直接决定了GC 怎么做多线程是否安全OOM 和 StackOverflowError 从哪来JVM 内存只分两大类一句话先记住线程私有只和当前线程有关线程共享所有线程共同使用这是理解GC、并发安全、内存异常的根本前提。1. 程序计数器最小但不可或缺本质记录当前线程正在执行的字节码位置线程切换后能从正确位置继续执行关键特点线程私有唯一不会发生 OOM 的内存区域高频速答为什么 Java 多线程切换不会乱一句话答案每个线程都有独立的程序计数器保存自己的执行位置。2. 虚拟机栈排错最常见栈的基本单位栈帧每一次方法调用都会创建一个栈帧包含局部变量表操作数栈动态链接方法返回地址局部变量表里有什么基本数据类型对象引用reference关键认知点对象在堆中栈中只保存引用两类典型异常必须能区分StackOverflowError方法递归过深栈帧不断入栈空间耗尽OutOfMemoryError与栈相关线程创建过多每个线程都要分配栈空间高频速答栈为什么是线程私有的一句话答案方法调用链不能被多个线程共享否则执行状态会混乱。3. 本地方法栈补充点为native方法服务HotSpot 中通常与虚拟机栈合并实现主要存储 native 方法执行过程中使用的参数局部变量返回值JNI 调用相关的上下文信息底层平台的调用状态。一般不单独深挖但要知道它属于线程私有。native 方法是指方法的实现不在 Java 代码中而是由 Java 以外的语言通常是 C / C实现的方法。4. 堆GC 的主战场堆的核心职责存放对象实例线程共享GC 管理的主要区域为什么堆要“分代”不是拍脑袋设计而是基于一个长期统计结论绝大多数对象存活时间非常短因此 JVM 才采用分代模型来降低 GC 成本。新生代结构与流转新生代分为EdenSurvivor FromSurvivor To对象流转路径Eden → S0 → S1 → Old每次 Minor GC存活对象复制到 Survivor年龄加 1达到阈值后晋升老年代老年代的特点对象存活时间长GC 次数少但代价高Full GC 的主要区域高频速答为什么 Minor GC 快Full GC 慢一句话答案新生代对象少且易回收老年代对象多且存活时间长。5. 方法区 / 元空间类的存储区JDK 8 的关键变化移除永久代PermGen引入Metaspace元空间为什么要这样改永久代的问题空间固定容易 OOM与堆强耦合元空间的优势使用本地内存可动态扩展更适合大量类加载如 Spring、动态代理高频点为什么永久代被移除一句话答案避免固定大小限制提升类加载场景下的稳定性。总结计数器保执行切线程不乱栈管调用堆管对象新生代快收老年代慢清类信息不进堆进元空间这套内存模型直接支撑了GC 设计并发模型JVM 性能优化四、对象从创建到回收的完整生命周期常态“你 new 一个对象JVM 到底干了什么”1. 对象创建全过程标准五步一步不能少类是否已加载没加载先触发类加载加载、链接、初始化分配内存在堆中为对象分配空间初始化零值实例字段设置默认值保证对象可用设置对象头包含类指针、GC 信息、锁信息等执行构造方法按代码逻辑完成初始化高配点对象创建的完整过程一句话答案检查类 → 分内存 → 清零 → 设对象头 → 调构造方法2. 内存分配方式为什么有两种对象分配的前提是堆内存是否连续。指针碰撞适用场景堆内存连续如 Serial、ParNew 收集器做法维护一个指针分配时指针向前移动特点实现简单分配速度快空闲列表适用场景堆内存不连续如 CMS、G1做法维护可用内存块列表从合适位置分配特点灵活维护成本更高高频点指针碰撞和空闲列表的区别一句话答案是否要求堆内存连续。3. 对象创建为什么是线程安全的因为对象创建发生在多线程并发环境下。JVM 主要提供两种方案方案一CAS 重试通过原子操作更新内存指针失败则重试优点通用缺点高并发下有性能损耗方案二TLAB线程本地分配缓冲区默认Thread Local Allocation Buffer核心思想每个线程在堆中预分配一小块内存线程内对象分配无需加锁特点无锁分配速度快大多数对象直接在 TLAB 中完成分配高频点JVM 默认是否开启 TLAB一句话答案是的默认开启用于提升对象分配效率。五、垃圾回收机制GC 底层原理GC 的核心只解决三件事对象死没死 → 怎么回收 → 何时回收得更优1. 如何判断对象已死为什么不用引用计数引用计数的问题只有一句话循环引用无法回收两个对象互相引用但外部已不可达引用计数不为 0却早该被回收。JVM 的标准答案可达性分析核心思想从一组“必然存活”的对象出发看能不能走到目标对象。这组起点叫GC Roots。常见 GC Roots虚拟机栈中的引用类静态变量常量池中的引用JNI本地方法引用结论规则从 GC Roots 不可达的对象才是可回收对象高频点JVM 如何判断对象是否可回收一句话答案通过 GC Roots 做可达性分析不可达即回收。2. GC 算法为什么要“组合使用”因为不同区域的对象特性完全不同。新生代复制算法特点对象存活率低回收频繁优势只复制存活对象回收速度快代价需要额外空间Survivor老年代标记-整理算法特点对象存活率高不能频繁移动优势避免内存碎片适合长期存活对象代价回收成本高核心结论没有万能 GC 算法只有场景最优组合。高频点为什么新生代和老年代用不同算法一句话答案因为对象存活率不同回收策略必须不同。3. G1 垃圾回收器主流G1 的出现本质是为了解决一个问题在大堆内存下如何控制 GC 停顿时间G1 的核心设计思想把整个堆拆成多个RegionRegion 可以是新生代也可以是老年代不再固定按代整体回收一句话理解不按“代”收按“价值”收什么是“回收价值”综合考虑Region 中垃圾比例回收收益回收成本优先回收性价比最高的 Region。为什么 G1 停顿时间可控核心原因只有两点每次只回收部分 Region可以根据目标停顿时间做回收计划这也是 G1 名字的来源Garbage First优先回收垃圾最多的区域。高频点G1 为什么能控制停顿时间一句话答案通过 Region 化和按回收价值选择回收范围。总结死没死看 Roots算法选型看存活率G1 不按代按价值收六、内存泄漏1. 内存泄漏的本质定义一句话定义对象已经没有业务意义但仍然被 GC Roots 间接或直接引用。关键点要说清楚不是“内存不够”而是引用关系断不开GC 按规则工作但规则失效于设计错误高频点什么是内存泄漏一句话答案对象该死但没死因为还在 GC Roots 引用链上。2. 常见泄漏场景的底层原因静态引用最基础为什么会泄漏静态变量生命周期 JVM 生命周期天然属于 GC Roots一旦静态集合、静态缓存不断增长对象永远不可回收高频点为什么静态变量容易导致内存泄漏一句话答案因为它们是 GC Roots生命周期过长。ThreadLocal 泄漏问题不在 ThreadLocal而在线程池。底层结构keyThreadLocal弱引用value业务对象强引用当ThreadLocal 被回收线程长期存活线程池结果value 仍被线程引用无法回收正确姿势必须说使用后finally 中调用 remove()高频点ThreadLocal 为什么会内存泄漏一句话答案线程不结束value 强引用还在。连接、流未关闭典型对象JDBC 连接SocketIO 流问题本质不仅占 JVM 堆还占用操作系统资源这种泄漏往往比 OOM 更危险。高频点为什么流不关闭问题严重一句话答案既泄漏内存又泄漏系统资源。3. 内存泄漏与 OOM 的关系一句话因果关系内存泄漏是原因OOM 是最终结果。少量泄漏 → 系统还能撑长期泄漏 → 必然 OOM高频点OOM 往往不是“突然发生”而是泄漏长期积累的必然结果。七、逃逸分析JIT 的核心优化能力让 JVM 判断“对象需不需要进堆”。1. 什么是逃逸标准定义对象是否可能被方法之外访问。不逃逸的典型特征只在方法内部使用不作为返回值不赋值给外部变量一句话记忆出不了方法的对象就是不逃逸。高频点什么是逃逸分析一句话答案JVM 判断对象作用域是否超出方法范围。2. JVM 为什么关心“逃逸”因为一旦确认不逃逸对象就没必要进堆。直接收益减少堆内存分配减少 GC 压力提升整体性能高频点逃逸分析的核心目的是什么一句话答案减少对象进入堆从而减少 GC。3. 三大核心优化1. 栈上分配结论型描述对象直接分配在栈上方法结束自动销毁不参与 GC适用前提对象不逃逸高频点什么是栈上分配一句话答案不逃逸对象直接在栈上分配。JVM 在逃逸分析后不再创建对象 而是把对象字段拆成标量可能分布在栈帧、操作数栈甚至寄存器中。2. 标量替换优化力度最大核心思想对象可以拆就没必要存在。做法把对象拆成多个基本类型变量对象本身彻底消失效果零对象创建零 GC 压力高频点什么是标量替换一句话答案把对象拆成基本类型彻底消除对象。3. 锁消除适用场景锁对象不逃逸没有多线程竞争JIT 判断后直接移除 synchronized 锁。高频点JVM 为什么能安全地消除锁一句话答案因为逃逸分析确认不存在并发访问。总结逃不逃看范围不进堆GC 少栈分配、标量换、锁直接消八、JVM 调优与问题排查1. 常见 OOM 类型先会分类Java heap space一句话含义堆中对象过多GC 回收不过来。常见原因内存泄漏大对象加载缓存无限增长Metaspace一句话含义类加载太多元空间被打满。常见原因动态代理 / CGLIB 过多类加载器无法回收热部署、插件化使用不当GC overhead limit exceeded一句话含义GC 拼命干活但几乎回收不到内存。本质判断系统已经处在“濒死状态”高频点OOM 常见有哪些类型一句话答案堆、元空间、GC 过载。2. 排查 OOM 的标准流程这一步比“调参”重要十倍。标准四步法确认 OOM 类型先判断是堆、元空间还是 GC 问题Dump 内存快照OOM 时或手动触发 Heap Dump分析对象引用链找出占用最多、不可回收的对象定位代码根因回到代码解决引用问题而不是只扩容高频点线上 OOM 你怎么排查一句话答案先定类型再看 Dump最后回到代码。3. 常用 JVM 排查工具不要求你精通但必须知道用来干什么。jps查看 JVM 进程快速确认目标进程 ID一句话找 JVM 进程用的。jstack查看线程栈排查死锁、线程阻塞一句话看线程状态。jmapDump 堆内存查看对象分布一句话看堆里的对象。jvisualvm图形化监控内存、线程、GC 情况一句话本地/测试环境快速分析。arthas线上诊断方法调用、参数、返回值无需重启一句话线上救火神器。总结OOM 先分型排查四步走jstack 看线程jmap 看对象arthas 救线上九、总结JVM 不是简单的虚拟机而是一个持续做运行期优化的系统GC 的本质不是“回收内存”而是分析对象之间的引用关系内存泄漏不是没 GC而是对象仍在 GC Roots 引用链上逃逸分析是 JIT 性能优化的前提没有它就没有高效优化G1 通过 Region 化和按价值回收成为当前服务端主流选择