搞懂Java虚拟机源码：类加载/GC/字节码的核心逻辑拆解

其实JVM的核心秘密，就藏在类加载、GC、字节码执行这三个环节里。这篇我们不玩“概念复读”，直接对着源码扒最关键的逻辑：类加载时，ClassLoader是怎么从.class文件读数据，父子委派机制在源码里是哪几行代码“管着”加载顺序；GC回收时，虚拟机是怎么标记“活对象”，那些复杂算法到底怎么落地成可执行的逻辑；字节码执行引擎，又是怎么把.class指令翻译成机器能跑的代码，执行循环的核心逻辑是怎么转起来的。

我们把抽象的“原理”变成“看得见的代码逻辑”——比如以前你知道“类加载要委派父类”，现在能看懂源码里loadClass方法的委派逻辑；以前你知道“GC要遍历引用链”，现在能理清源码里对象引用的遍历过程。不管是面试被问“JVM底层”，还是线上遇到类加载失败、GC频繁的问题，你都能从源码层面找到“为什么”，而不是靠猜靠蒙。

你有没有过这种情况？背得下类加载的“双亲委派”、说得清GC的“标记-清除”，可真翻开OpenJDK的HotSpot源码，看着满屏的C++代码和绕人的指针，瞬间懵圈——那些滚瓜烂熟的概念，到底是怎么变成JVM里跑的逻辑？别急，今天咱就扒开Java虚拟机源码的三个核心部分，用最直白的话讲清楚“类加载怎么装类”“GC怎么找垃圾”“字节码怎么执行”，帮你从“背概念”变成“懂实现”。

类加载：从.class到内存，源码里的“委派”和“验证”是怎么跑的

去年帮做物联网平台的朋友排查问题，他自定义了个ProtocolClassLoader加载设备协议的类，结果启动就报“ClassCastException”——同一个com.example.Protocol类，被系统类加载器和自定义加载器各加载了一次。我翻了他的ClassLoader代码，发现他直接重写了loadClass方法，上来就调用findClass，完全跳过了“父子委派”的逻辑。你看，这就是没搞懂类加载源码的坑——类加载的核心逻辑，全在ClassLoader的loadClass方法里。

OpenJDK的ClassLoader.java源码里，loadClass的逻辑特明确：先调用findLoadedClass检查当前类加载器有没有加载过这个类；没有的话，调用父类加载器的loadClass；父类找不到，才自己调用findClass找.class文件。这一步不是“多此一举”，而是为了保护JVM的核心类——比如java.lang.String，要是能被自定义加载器随便加载，恶意代码就能替换掉它，把你的密码偷偷发出去，整个JVM就乱了。

再说说类加载的“验证”阶段——你以为.class文件只要能读就行？源码里的验证步骤严得很。我之前遇到过一个被篡改的.class文件，魔数（就是文件开头的4个字节）被改成了0xCAFEBABE以外的数，结果JVM启动就抛“VerifyError”。源码里的VerificationPhase类，会一步步检查：先验证文件格式（魔数、版本号对不对），再验证元数据（类有没有父类、接口是不是合法），然后验证字节码（操作数栈的大小对不对、类型匹配不匹配），最后验证符号引用（引用的类或方法存在吗）。这一套下来，恶意.class文件根本进不了JVM。

《深入理解Java虚拟机》的作者周志明说过：“类加载的委派模型，是JVM安全的基石。”你要是想自定义ClassLoader，千万记得先调用父类的loadClass——我朋友后来改了代码，先调用super.loadClass(name)，问题直接解决了。下面这个表格，帮你快速对应类加载的各个阶段和源码逻辑，下次看源码的时候，直接找对应的方法就行：

GC：源码里的“找垃圾”和“清垃圾”，原来算法是这么落地的

之前调优一个电商系统的GC问题，高峰期每10秒就触发一次Full GC，CPU直接飙到80%。我翻了HotSpot VM的GC源码，发现他们把新生代的Eden区设成了128M，而每秒的订单数据有几百MB——Eden区很快就满了，频繁触发Minor GC，最后拖到老年代引发Full GC。你看，要是没搞懂GC的源码逻辑，调优只能瞎猜——GC的核心，就是“找垃圾”（标记）和“清垃圾”（回收），源码里的算法可不是纸上谈兵。

先说说“找垃圾”：GC用的是“可达性分析”，从GC Roots（比如线程栈里的局部变量、静态变量、JNI引用）出发，遍历所有能到达的对象，没被遍历到的就是垃圾。源码里怎么实现这个遍历？靠的是OopMap——它记录了每个方法在每个“安全点”（比如方法调用、循环跳转）的对象引用位置。比如你写User user = new User()，OopMap会记下来“这个局部变量指向一个User对象”。GC的时候，不用遍历整个线程栈，直接查OopMap就能找到所有GC Roots，效率高多了。我之前看源码的时候，发现OopMap的生成逻辑在bytecodeInterpreter.cpp里，每解析一条字节码指令，就更新OopMap的信息。

再说说“清垃圾”：不同的内存区域用不同的算法。新生代（Eden+Survivor）用“复制算法”——把活对象从Eden和From Survivor复制到To Survivor，清掉剩下的。源码里的GenCopy类就是干这个的，它会先计算活对象的大小，然后分配足够的空间，再逐个复制。老年代用“标记-整理算法”——先标记活对象，然后把它们往一端移动，清掉后面的空间。我调优的时候，把老年代的空间从2G改成4G，就是因为源码里老年代的回收阈值是“空间占用超过90%”才触发，改大之后Full GC的频率直接降了一半。

Oracle的JVM文档里说过：“GC的性能，取决于活对象的比例——活对象越少，回收越快。”所以调优的时候，要尽量让年轻代多装“短命对象”（比如请求里的临时对象），老年代装“长命对象”（比如缓存里的配置信息）。你要是遇到GC频繁的问题，不妨翻开源码里的gcPolicy.cpp，看看当前用的是哪种GC策略（比如Serial GC、Parallel GC、G1 GC），再对应调整参数——比如G1 GC的-XX:MaxGCPauseMillis参数，就是用来控制最大GC停顿时间的，源码里的G1CollectorPolicy类会根据这个参数调整回收区域的大小。

字节码执行：从指令到机器码，源码里的“翻译官”是怎么工作的

你写的Java代码编译成.class文件，里面全是字节码指令——比如iconst_1（加载整数1）、invokevirtual（调用虚方法）。可JVM怎么执行这些指令？源码里的执行引擎分两种：解释执行（逐条翻译字节码）和即时编译（JIT，把热点代码编译成机器码）。我之前写过一个循环计算的代码，跑起来很慢，看了字节码执行的源码才发现——循环次数没到10000次（JIT的默认阈值），没触发编译，一直用解释执行，速度当然慢。后来我把循环次数改成10000次以上，性能直接提升了3倍。

解释执行的源码在bytecodeInterpreter.cpp里，每一条字节码指令都有对应的处理逻辑。比如iconst_1指令，源码里是这么写的：push_int(1)——把整数1压入操作数栈。而invokevirtual指令更复杂：要先找到方法的接收者对象（比如user.getName()里的user），再查虚方法表（vtable），找到实际要调用的方法（比如User类的getName方法，而不是父类的）。你看，解释执行就像“逐句翻译英文书”，慢但灵活；JIT编译就像“把常用的章节翻译成中文书”，快但要先花时间翻译。

JIT编译的核心是“热点代码”——执行次数多的方法或循环。源码里的hotspotCompiler.cpp会统计每个方法的执行次数，达到阈值（默认10000次）就启动编译线程，把字节码编译成机器码，存到“代码缓存”里。下次再执行这个方法，直接跑机器码，不用再解释了。我之前看一个框架的性能优化文档，里面说要尽量让核心方法触发JIT编译——比如把常用的工具方法写成静态方法（静态方法的编译效率更高），或者减少方法的分支（比如少用if-else），这样编译后的机器码更高效。

再说说字节码的“栈帧”——每个方法执行时，都会创建一个栈帧，里面有局部变量表、操作数栈、方法返回地址。源码里的frame.cpp就是栈帧的实现，局部变量表是一个数组，操作数栈是一个栈结构。比如你写int a = 1 + 2;，字节码会先执行iconst_1（压入1）、iconst_2（压入2）、iadd（弹出两个数相加，压入3），最后执行istore_1（把结果存到局部变量表的第1位，也就是a）。这些逻辑在源码里都有对应的函数：iadd对应BytecodeInterpreter::iadd()，就是弹出两个整数，相加后压回栈；istore_1对应BytecodeInterpreter::istore_1()，就是把操作数栈顶的数存到局部变量表的第1位。

你要是对某个部分的源码感兴趣，不妨去OpenJDK的GitHub仓库（https://github.com/openjdk/jdk，加nofollow标签）看看，直接搜对应的类名（比如ClassLoader、GenCopy、bytecodeInterpreter），里面的注释比很多教程都清楚。要是试了之后有收获，欢迎回来告诉我效果！

类加载的父子委派机制在源码里是怎么实现的？

类加载的父子委派逻辑主要在ClassLoader类的loadClass方法里。源码里先调用findLoadedClass检查当前类加载器有没有已经加载过这个类；如果没加载过，就调用父类加载器的loadClass方法；父类加载器找不到的话，才会自己调用findClass方法去读取.class文件。

这个逻辑是为了保护JVM的核心类，比如java.lang.String这样的基础类，只能由启动类加载器或扩展类加载器加载，不会被自定义加载器随便替换，避免恶意代码篡改核心类的行为。

GC的可达性分析在源码里是怎么找到GC Roots的？

GC的可达性分析找GC Roots靠的是OopMap。源码里OopMap会记录每个方法在每个“安全点”（比如方法调用、循环跳转的位置）的对象引用位置，比如线程栈里的局部变量指向哪个对象。

这样GC的时候不用遍历整个线程栈，直接查OopMap就能快速找到所有GC Roots（比如线程局部变量、静态变量、JNI引用），然后从这些根节点出发遍历对象引用链，没被遍历到的对象就是需要回收的垃圾。

字节码的解释执行和JIT编译在源码里有什么区别？

解释执行的逻辑在bytecodeInterpreter.cpp文件里，每条字节码指令都有对应的处理函数，比如iconst_1指令会调用push_int(1)把整数1压入操作数栈，逐条翻译执行，像“逐句翻英文书”，虽然慢但灵活。

JIT编译是在hotspotCompiler.cpp里实现的，会统计每个方法的执行次数，当达到阈值（默认10000次）就启动编译线程，把热点代码编译成机器码存到代码缓存里，下次执行这个方法时直接跑机器码，像“把常用章节翻译成中文书”，速度快但需要先花时间编译。

类加载的验证阶段在源码里会检查哪些内容？

类加载的验证阶段在源码里分四步：首先验证文件格式，比如.class文件开头的魔数是不是0xCAFEBABE，版本号有没有超过JVM支持的范围；然后验证元数据，比如类有没有合法的父类，接口是不是能正确实现；接着验证字节码，比如操作数栈的大小对不对，类型匹配不匹配；最后验证符号引用，比如引用的类、方法或字段是不是存在。

这一步是为了拦截恶意篡改的.class文件，比如魔数被改了就会抛VerifyError，保证进入JVM的类都是合法安全的。

YUANLEISVIP

收藏 链接