1. JVM是什么为什么Javaer必须搞懂它先说个我踩过的坑。有一次某个基于Java开发的后台服务在连续运行一周后突然响应变慢接着频繁出现Full GC告警CPU占用率一路逼近100%。当时第一反应是代码写得太烂把业务代码翻了个底朝天也没找到明显的热点后来才意识到问题发生在应用本来就该自动完成的内存管理机制上——对象没被及时回收、老年代被塞满、堆碎片化严重。那一周我几乎把JVM相关的内容从头啃了一遍之后才发现很多Java开发者的进阶瓶颈不在语法、不在框架而卡在“根本不知道Java运行时到底在你的机器上做了什么”。JVM全称Java Virtual Machine中文叫Java虚拟机。它不是一台实体的机器而是一个规范、一套运行时的抽象计算机。Java源码会被编译成字节码字节码不直接跑在操作系统上而是跑在JVM里。JVM再通过解释器、即时编译器把字节码翻译成当前机器能执行的机器指令。这就是Java“一次编译、到处运行”的来源只要某个平台上有符合规范的JVM实现同一种字节码就能在该平台上运行而不需要针对Windows、Linux、macOS分别编译一套版本。但JVM能解决的问题远不止“跨平台”。它负责帮你管理内存、回收垃圾对象、调度线程、加载类甚至会在运行期对你的热点代码做深度优化。换句话说你写的Java代码只是表达“业务逻辑”真正让程序跑得又快又稳的是JVM在你背后默默干的那堆活。不理解它的运行机制遇到性能问题就只能靠感觉猜理解了它你才能从“代码能跑”跨越到“代码跑得好”。这篇内容适合谁看正在学Java想弄明白“new出来的对象去了哪里”、工作一段时间想系统补一下JVM知识、或者遇到OOM和GC相关问题不知道从哪下手的开发者都值得认真读一遍。我会从架构到调优、从原理到实战一步步拆开不绕弯子直接讲清楚每一个关键环节顺带把我在项目中真实遇到过的问题和排查方法也放进来。2. 整体架构拆解JVM运行时由哪些模块组成2.1 三个核心子系统与运行流程JVM整体上可以拆成三块类加载子系统、运行时数据区、执行引擎。再加上本地方法接口就构成了它和操作系统交互的桥梁。流程图可以这样理解字节码文件先进类加载子系统由它负责把.class文件读入内存并完成校验和初始化准备之后字节码被分配进运行时数据区也就是我们常说的“JVM内存”执行引擎拿到字节码后一边解释执行一边通过即时编译把它转成高效的本地机器码。整个过程中本地方法接口允许Java程序调用操作系统或C/C编写的底层能力比如底层文件操作、时间相关系统调用等。这三个子系统各自承担什么责任必须分清楚。类加载子系统不只是“读一个文件”它要处理类名的解析、父类加载、接口实现关系、常量池解析等一系列复杂动作。运行时数据区是程序的运行舞台所有对象的分配、方法调用的栈帧、线程计数器都在这里工作。执行引擎是整个JVM里性能影响最大的一块包含解释器、即时编译器和垃圾收集器相关的执行辅助逻辑直接决定了你的热点代码能不能跑出接近汇编的效率。我刚学JVM时最大的误区是以为它就是个“内存容器”其实不是。内存只是运行时数据区JVM还负责指令级的执行调度。你把JVM当成一台自己会管理寄存器、栈、堆的虚拟电脑很多概念就顺了。2.2 运行时数据区的五大区域详解运行时数据区里最常聊的就是五个部分程序计数器、虚拟机栈、本地方法栈、堆、方法区。程序计数器每个线程私有记录当前线程正在执行的字节码指令地址。它极其轻量不占用多少内存也是最不会出问题的区域。它唯一规定的异常场景是执行native方法时计数器值为空因为native方法不通过字节码执行。虚拟机栈同样线程私有。每个Java方法调用时JVM都会创建一个栈帧压入当前线程的虚拟机栈。栈帧里存放了局部变量表、操作数栈、动态链接、方法出口等信息。方法一层层嵌套调用栈帧就一层层叠加递归调用太深或者栈帧过大时就会抛出StackOverflowError。为什么线程被创建时需要设置栈大小本质就是约束一层层方法调用能占用的内存上限。本地方法栈是给native方法用的。HotSpot虚拟机把本地方法栈和虚拟机栈合并成了一个所以通过-Xss设置的值同时影响两者。一般开发中不常动它但理解它在线程模型里的位置很有必要。堆这是JVM管理内存的核心地带也是垃圾回收器工作的主要区域。Java中几乎所有对象实例和数组都在这里分配逃逸分析后栈上分配的除外。堆是所有线程共享的因此存在并发访问安全问题JVM在这里引入了锁机制、TLAB机制来保证分配效率。堆又分新生代和老年代新生代里继续划分Eden区和两个Survivor区后面我会详聊。方法区存储已被虚拟机加载的类型信息、常量、静态变量、即时编译后的代码缓存。在JDK 8之前方法区的实现被称为永久代JDK 8之后用元空间替代直接使用本地内存。很多老资料说“永久代在堆内”但那是此前实现细节不是规范要求。理解区分规范叫方法区实现叫元空间它们的关系是接口与实现。2.3 执行引擎与即时编译器执行引擎负责真正“运行”字节码。HotSpot里有两套执行方式解释执行和编译执行。JVM启动时解释器先把字节码逐条翻译成本地指令速度慢但启动快随着代码被反复执行JVM会统计调用次数和循环回边次数超过阈值就交给即时编译器JIT编译成机器码缓存下来后续直接执行机器码速度极快。HotSpot内置了C1和C2两套即时编译器有些版本还引入Graal。C1适合客户端场景编译快但优化弱C2适合服务端场景编译慢但优化深。JDK 10之后还支持分层编译让方法先经过C1快速编译再在热度足够高时升级到C2深度优化。这个机制的直接效果就是Java服务端程序跑得越久热点代码优化得越到位吞吐量往往越高。3. 对象的一生从new到被回收3.1 对象创建的完整流程一句简单的new Object()背后远没有看上去那么简单。JVM收到new指令后会先去方法区常量池中找到对应的类符号引用检查这个类是否已加载、解析、初始化没有的话就先触发类加载。类加载通过后JVM要为对象分配内存。分配内存的“空间”大小在类加载时就能确定就像装箱时先量好尺寸。之后的分配动作有两方面细节。一是堆内存指针是否并发安全。如果内存规整使用“指针碰撞”从头开始画一块区域如果内存碎片多则用“空闲列表”寻找足够大的空间。并发情况下需要用CAS加失败重试或者使用TLAB为每条线程预先分配一块小空间绝大多数普通对象在TLAB内分配减少同步开销。分配完成JVM会将内存空间初始化为零值接着设置对象头。对象头里记录了哈希码、GC分代年龄、锁状态标记等关键信息。然后执行init方法按照Java语义完成属性的显式赋值和构造器代码执行。到这里一个对象才算真正“活”了。3.2 内存分配规则与逃逸分析对象默认在堆中分配但HotSpot做了不少优化。最常见的是逃逸分析如果对象只在方法内部使用、不会被其他线程访问、也不会作为返回值传出JVM可以把它的内存分配在虚拟机栈上。方法结束时栈帧出栈对象随帧销毁完全不需要垃圾回收参与这是消除GC压力最直接的一种手段。与之配套的是标量替换把对象字段直接拆成局部变量装进栈帧减少对象头带来的内存开销。我实际观察过一个纯计算型短小方法通过逃逸分析成功栈上分配之后接口的响应延迟和GC次数都有明显下降。不过这个优化依赖方法复杂度太复杂的调用未必能触发。常规情况下对象分配走TLAB。Eden区空间不足时JVM才在堆上以CAS方式直接分配。一个对象如果足够大大到Eden放不下会直接试着进老年代。另外新生代中每经历一次Minor GC仍存活的对象年龄会增加一岁默认达到15岁就晋升到老年代。这个阈值可以通过-XX:MaxTenuringThreshold设置不同收集器默认值不同。3.3 可达性分析与判定存活垃圾回收器判断对象是否该回收主流方式是可达性分析。以GC Roots作为起点向下搜索引用链链条上碰不到的对象被认为是不可达对象也就是可以被回收的对象。GC Roots包括虚拟机栈中引用的对象、方法区中静态属性引用的对象、方法区中常量引用的对象、本地方法栈中JNI引用的对象、被同步锁持有的对象等。写代码时一句“我的对象被置成null了怎么还没被回收”很常见这对应了一个重要概念可达性判定不等于立即回收。一个对象即使被判定为可回收至少要经过两次标记。第一次标记后它会进入一个等待队列如果对象本身重写了finalize()方法且方法还未被调用过则有机会在finalize里把自己重新连上引用链从而“复活”一次。但我建议你永远不要依赖finalize来做资源释放或者逃生它完全不确定何时调用写完当没有最好。另外Java的引用类型远不止强引用还有软引用、弱引用、虚引用。软引用适合做内存敏感的缓存JVM要OOM前会回收软引用对象弱引用对象活不过下一次垃圾回收虚引用主要用于跟踪对象回收配合引用队列做资源清除。我做过一个图片缓存模块用软引用包一层内存充足时缓存命中率很高内存告急也不会拖垮进程算是最常用的技巧。4. 垃圾回收从基础算法到主流收集器选型4.1 三个基础回收算法扫盲标记-清除算法先标记可回收对象然后统一回收。它最大问题是产生大量内存碎片导致后续分配大对象时明明空间够却找不到连续区域。标记-复制算法把内存分成两块每次只用一块GC时把存活对象一次性复制到另一块再整体清掉当前块。它解决了碎片问题但代价是浪费一半空间。新生代针对“朝生夕灭”的特点对这块做了改良不需要把内存均分而是把Eden和两个Survivor按8:1的默认比例划分只有10%的空间被闲置。每次Minor GC把Eden和一个Survivor里的存活对象复制到另一个Survivor剩余直接清空。如果Survivor放不下就通过分配担保机制把多余对象挪进老年代。标记-整理算法适合老年代。先标记存活对象然后把存活对象向一段移动使内存紧凑。移动对象成本高但避免了碎片。CMS收集器为什么会频繁触发Full GC很大原因就是它用标记-清除导致碎片积累老年代空间看似剩余实际连续空间不足。4.2 分代收集理念与跨代引用堆分成新生代和老年代是分代理论的落地。新生代存放生命周期短的对象GC频繁且快老年代存放生命周期长的对象GC次数少但耗时高。绝大多数对象迅速死亡这一观察结果直接影响了收集器的设计。Minอร์GC通常只回收新生代Full GC回收整个堆。跨代引用是个隐蔽问题。老年代对象可能引用了新生代对象Minor GC在找GC Roots时不可能扫描整个老年代。HotSpot用记忆集Remembered Set来记录老年代中哪些区域可能存在跨代引用GC时只需要额外处理这些“脏卡页”即可。这个机制大大减少了扫描范围也是保证Minor GC效率的关键设计之一。4.3 主流垃圾收集器对比与选型Serial单线程收集器暂停所有用户线程进行回收。简单可靠适合客户端或堆较小的场景。Serial OldSerial的老年代版本用标记-整理主要服务老年代或作为CMS的兜底方案。ParNewSerial的多线程版本配合CMS用。优势是在高频应用中减少STW时间。Parallel Scavenge目标是控制吞吐量适合后台计算任务配合Parallel Old使用。CMS第一款追求低停顿的收集器基于标记-清除并发收集老年代但缺点明显CPU敏感、无法处理浮动垃圾、会退化成Serial Old做Full GC。G1分Region设计兼顾可预测停顿时间把堆分成若干大小相同的Region优先回收收益最大的Region。JDK 9开始成为默认收集器。ZGC支持TB级堆的低延迟收集器停顿时间控制在10毫秒级别利用染色指针和读屏障实现并发处理适合超大堆、低延迟要求极高的场景。选型没有绝对标准要结合堆大小、延迟SLA、吞吐量需求来判断。我做过的在线交易系统堆内存约8GB目标GC停顿必须控制在100毫秒以内用的G1加适度停顿预测配置效果比之前CMS稳定很多。而一个离线批处理任务跑完了就行不要求响应时间用Parallel Scavenge反而吞吐更香。5. 类加载机制与双亲委派模型5.1 加载、链接、初始化三个阶段类加载机制是JVM里容易被低估的部分。很多人以为类加载就是把.class读进内存实际上它分为三个阶段加载、链接、初始化。其中链接又细分验证、准备、解析三步。加载阶段类加载器根据全限定名获取此类的二进制字节流把字节流所代表的静态存储结构转换为方法区的运行时数据结构并在堆中生成一个java.lang.Class对象作为访问方法区的入口。验证阶段目的是保证字节流符合JVM规范不会危害虚拟机自身安全。包括文件格式验证、元数据验证、字节码验证和符号引用验证四类。这个阶段虽然严格但很多项目通过-Xverify:none或-noverify跳过部分验证来加快启动生产环境是否启用要看你对依赖方信任程度。我不建议为了快那零点几秒关掉验证特别是引入了外部SDK时坑都是从这里埋下的。准备阶段为类的静态变量分配内存并设置默认初始值。比如static int value 100准备阶段先把value设为0等到初始化阶段再赋值100。注意如果是static final常量在准备阶段就会直接赋值。解析阶段将常量池中的符号引用替换为直接引用。这时候类的信息会在方法区中固化引用关系。初始化阶段真正执行类构造器clinit方法完成静态变量赋值和静态代码块的执行。这里有个特点clinit由JVM保证只有一条线程能执行所以类初始化天然线程安全。5.2 双亲委派模型详细拆解双亲委派模型是类加载器工作的核心机制。除了启动类加载器Bootstrap ClassLoader其他类加载器都有一个父加载器。收到加载请求时先让父加载器尝试加载父加载器无法加载时才由自己处理。这种“向上的委派、向下的失败”保证了基础类库的一致性比如你自己写了一个java.lang.String实际上永远无法覆盖JDK自带的String因为引导类加载器已经优先加载了系统版本。三个默认类加载器全链启动类加载器负责加载JAVA_HOME/lib下的核心类或-Xbootclasspath指定的类扩展类加载器JDK 9后叫平台类加载器负责加载扩展目录下的类应用类加载器负责加载classpath下的类。它们共同构成一条链应用类加载器请求平台类加载器平台类加载器请求启动类加载器没有加载到再一层层回落。双亲委派的意义在于沙箱安全和全局唯一性。我记得有同事把公司的某个公共jar放在classpath里也把另一个同名类的路径排在前面结果类加载版本错乱方法缺字段一堆NoSuchMethodError。后来排查发现是不同加载器在同一名称空间加载了重复类。遇到这种问题优先检查依赖版本冲突和类加载器关系。如果非要打破双亲委派比如实现热部署、自定义动态模块就得通过重写loadClass方法来实现。但这条路要付出很大代价你要自己管理类卸载、版本隔离、上下文类加载器切换。普通业务项目不建议碰除非你真的在做JRebel式热加载工具或者OSGi容器。6. JVM调优与排障实战6.1 高频JVM参数图解与常用配置JVM参数多到记不住但常用的就那几十个。以下是我每次服务上线前都会核对的核心项参数作用默认值示例建议-Xms / -Xmx初始堆 / 最大堆通常是物理内存1/4启动时设成一致避免运行期动态扩展-Xmn新生代大小无固定老年代占整堆2/3左右比较常见-XX:MetaspaceSize元空间触发Full GC阈值约20.8MB根据类数量逐渐加大-XX:MaxMetaspaceSize元空间上限无限不设上限可能失控-XX:UseG1GC启用G1收集器JDK9后默认低延迟优先可用G1-XX:HeapDumpOnOutOfMemoryErrorOOM时导出堆快照默认关必须开启否则OOM后没证据-XX:MaxDirectMemorySize最大直接内存默认同堆用NIO要留意-XX:MaxTenuringThreshold晋升老年代阈值15一般不必改上面表格里从-B开始的设计很容易有误区比如MaxDirectMemorySize不只影响DirectByteBuffer还影响Unsafe分配的内存。很多堆外内存泄漏排查半天堆dump全正常最终定位到这里。务必记住JVM内存和堆外内存不是一个概念。堆大小设置的核心经验是不要拍脑袋。先按峰值负载估算活跃对象总量再留出一定余量堆太小频繁GC堆太大单次GC停顿时间拉长。一般建议-Xmx不超过物理内存的50%左右算上堆外开销。6.2 诊断工具定位法jstat、jmap、jstack、MAT组合拳线上问题排查先用jstat看GC概况再用jmap看堆。jstat -gcutil pid 1000 5能看到新生代、老年代使用比例、GC次数和耗时。如果老年代使用率持续高位、Full GC执行频繁说明要么对象增长速度超过回收能力要么存在对象长期被引用不释放。jmap -heap pid查看堆详情jmap -dump:live,formatb,fileheap.bin pid导出堆快照。其中live表示只导出存活对象文件更小但会触发Full GC线上谨慎使用。导出后用MAT或VisualVM分析重点看Dominator Tree找到持有大多数内存的对象和它的GC Roots引用链。我排查过一个内存泄漏定位到某个缓存类把用户的会话对象全部放进了一个无过期策略的Map就是从Dominator Tree一路追到Map的Entry。jstack输出线程快照适用于线程死锁、CPU飙高场景。CPU飙高时先用top -Hp看看是哪条线程在吃CPU再用printf把十进制线程ID转成十六进制在jstack输出里找到这条线程的栈定位到业务代码热点。这是排查无限循环和密集计算最常用的一套路径。6.3 一次典型OOM排查实录去年负责的一个报表服务每天凌晨生成统计任务时频繁OOM。先从告警里收集到堆dump文件用MAT打开后发现有个LineChartData的实例集合占据了接近2GB内存。检查引用路径发现某个线程池里的任务在执行完成后结果集被放进了静态ConcurrentHashMap但Map的清理逻辑因为异常被跳过旧任务的数据一直堆积。排查思路可以总结成一套标准流程先确认是堆内存OOM还是元空间/直接内存OOM看报错提示里有Java heap space还是Metaspace字眼。堆OOM就导出dump选取dump时机尽量接近崩溃前。分析大对象和引用链定位是“对象太多”还是“对象不可回收”。如果是对象不可回收顺着GC Roots链路找出是谁强引用着它。修复之后压测验证重点盯老年代增长曲线和GC频率是否回归正常。这套方法下来不用蒙。前提是你把HeapDumpOnOutOfMemoryError参数提前打开不然后台服务一旦重启当时现场全部丢失。6.4 GC日志分析与调优闭环GC日志是调优最基础的数据来源。JDK 9前用-XX:PrintGCDetails -XX:PrintGCDateStamps开启JDK 9后用-Xlog:gc*:filegc.log。日志里重点看几个指标单次GC停顿时间、停顿频率、晋升到老年代的对象大小、每次都发生Full GC吗。我就靠GC日志调过一例某个服务Minor GC频率高达每秒两三次但Eden区使用率始终不高。分析日志后发现Survivor空间设置太小对象在Minor GC时无法在Survivor间复制频繁晋升老年代老年代又被快速填满导致Full GC连环发生。把-Xmn调大并增加SurvivorRatio之后Minor GC频率明显降低应用响应时间稳定下来。调优不是调完就完要建立闭环设置参数、压测、观察GC日志、对比指标、再调整。我习惯把每次变更记录版本和生效结果避免改来改去忘了哪版最优。7. 常见问题速查与独家避坑心得问题现象大概率原因建议排查动作java.lang.OutOfMemoryError: Java heap space堆空间不足或存在泄漏导出堆dumpMAT查Dominator Treejava.lang.OutOfMemoryError: Metaspace动态生成类过多检查反射或CGLIB代理类数量java.lang.OutOfMemoryError: Direct buffer memory堆外内存耗尽检查DirectByteBuffer使用和释放java.lang.StackOverflowError递归过深或线程栈过小检查递归出口与-Xss设置频繁Full GC但老年代空间低Survivor不足致晋升过早调大-Xmn和SurvivorRatioCPU飙高但业务代码无明显热点大量GC线程或JIT编译阶段结合jstack、jstat和GC日志综合判断避坑心得这里多说几句。第一线程池中的线程栈大小别乱改改小容易StackOverflow改大浪费内存默认值一般够用。第二生产环境不要轻易关验证、不要随意开调试端口安全和稳定性永远比那点性能重要。第三JVM参数你可以在本地单测里验证启动结果但最终配置必须经过压测环境验证。第四调优要有明确指标没有目标地乱调参数等于浪费时间。第五JVM规范版本演进带来的行为变化要留意JDK 8的经验迁移到JDK 17不一定完全适用比如元空间、默认垃圾收集器、字符串去重这些都在变。个人经验之谈学JVM一定要带案例学、带问题学。只看原理书像读天书一边碰OOM一边查堆dump你会很快把可达性分析、引用类型、垃圾收集器这些概念全部串起来。真到了线上出了问题你脑子里有一套体系化的排查链路就不会慌。最后再分享一个我常用的技巧写一个小Demo强制制造内存泄漏——在一个被静态引用的容器里持续放入对象然后用JVM参数启动它自己走一遍堆dump、MAT分析、定位根因的全流程。做过一次JVM整个知识体系会通很多。之后领导再问“这个Java服务为什么内存涨不停”你就能拿出数据、指出对象、找到代码行而不是说一句“可能内存泄漏吧”。这就是从原理到实践最实在的进步。