★ FEATURED ARTICLE 1. 从一份“找不到北”的源码压缩包说起很多人第一次把JVM源码包解压开看到满屏的目录和文件第一反应是“这都什么跟什么”。hotspot、jdk、langtools、nashorn、corba……十几个顶层目录一字排开每个里面又是层层嵌套的子目录光看名字根本猜不出哪个才是JVM真正的“心脏”。我当初也是这么过来的下载完源码打开根目录鼠标滚轮滚了三遍愣是不知道该点进哪个文件夹。这篇文章就是来解决这个问题的。它不打算教你写JVM、也不打算逐行分析C代码而是聚焦一件更基础、但几乎所有人都会卡住的事把JVM源码的目录结构彻底理清楚。搞清楚哪个目录对应哪个模块、哪个文件负责哪块功能、它们之间是什么关系你后面无论是想读GC代码、看JIT编译流程还是研究类加载机制都能直接定位到目标文件而不是在几十个目录里瞎转。适合谁看如果你已经会写Java、用过JVM调优参数但从来没打开过JVM源码或者打开过但被目录结构劝退那这篇就是写给你的。我会用“先看地图再进城市”的方式从顶层目录一路拆到HotSpot内部的核心子目录把每个目录的职责、关键文件、以及“为什么这样划分”讲清楚。全程不堆术语遇到复杂概念就用生活化的类比解释保证你看完能自己画出JVM源码的目录地图。提示本文基于OpenJDK的经典目录布局展开不同版本之间目录名称和层级会有细微差异但核心模块的划分逻辑是一致的。读的时候重点关注“为什么这样分”而不是死记某个版本的具体路径。2. 顶层目录先分清“JDK全家桶”和“JVM本体”打开OpenJDK源码根目录你会看到一堆并列的文件夹。很多人误以为这些全都是JVM的代码其实不是。顶层目录里只有一部分跟JVM直接相关剩下的属于JDK的其他组件。先把这层关系理清后面才不会迷路。2.1 顶层目录的职责划分我习惯把顶层目录分成三类JVM本体类、JDK工具与库类、辅助与构建类。下面这张表是我自己整理的核心目录对照你可以直接拿来当速查表用。目录名类别核心职责是否JVM本体hotspotJVM本体JVM运行时核心含GC、JIT、类加载、解释器是jdkJDK工具与库Java类库源码java.lang、java.util等否langtoolsJDK工具与库javac编译器、javadoc等工具源码否nashornJDK工具与库JavaScript引擎实现否corbaJDK工具与库CORBA相关支持新版本已移除否make辅助与构建构建脚本和编译规则否test辅助与构建测试用例集合否这张表里最关键的一行就是hotspot。JVM源码入门90%的精力都应该花在这个目录里。其他目录不是不重要但它们属于JDK层面的东西跟你理解“JVM怎么跑Java代码”这件事关系没那么直接。2.2 为什么hotspot是绝对核心hotspot这个名字来源于它的一个核心技术特征热点代码探测。JVM在运行时会监控哪些方法被频繁调用把这些“热点”方法交给JIT编译器编译成本地机器码从而大幅提升执行效率。这个机制是整个JVM性能优势的根基所以这个目录就叫hotspot。你可以把hotspot理解成JVM的“发动机舱”。里面装着类加载系统负责把.class文件读进来、验证、准备、解析、初始化运行时数据区堆、栈、方法区、程序计数器等内存结构的实现执行引擎解释器、JIT编译器、GC收集器本地接口JNI的实现而jdk目录里的东西更像是“车身和内饰”——Java类库、工具、API。你写Java代码时调用的String、ArrayList、HashMap它们的源码在jdk目录里但这些类被加载、被编译、被回收的过程全部由hotspot目录里的代码控制。注意有些教程一上来就让你读jdk/src/share/classes/java/lang/Object.java这没错但那是Java类库层面的事。如果你想理解JVM本身第一步应该是进hotspot而不是进jdk。2.3 版本差异带来的目录变化不同版本的OpenJDK顶层目录会有出入。比如早期版本有corba和nashorn后来被移除了JDK 9引入模块化之后jdk目录的内部结构也发生了大调整。但hotspot这个目录名和它的核心地位从很早一直保持到现在。我建议你在读源码之前先确认自己用的是哪个版本然后对照该版本的官方目录说明看一眼。不用背知道“我读的是哪个版本、这个版本里哪些目录已经没了”就够了。我自己的习惯是在源码根目录放一个README-版本.txt记录版本号和目录变动省得下次打开又忘。3. 进入hotspotJVM真正的“五脏六腑”从根目录进到hotspot你会看到它下面又分了好几个子目录。这一层是很多人第二次迷路的地方——src、make、test、agent……看起来又是一堆并列项。别急这一层的逻辑比顶层清晰得多因为hotspot的目录划分基本就是按“功能模块”来的。3.1hotspot子目录的功能地图先看整体划分子目录职责重要程度src所有JVM核心源码最高make编译构建脚本中testJVM层测试用例中agentJVMTI代理相关低入门阶段可跳过os操作系统相关代码部分版本独立中入门阶段你99%的时间都会花在src目录里。其他目录要么是构建用的要么是测试用的要么是特定场景才涉及的。所以下面重点拆src。3.2src内部的“按语言分家”进到hotspot/src你会看到类似这样的结构src/ share/ os/ os_cpu/ cpu/这是HotSpot源码组织的一个核心设计按“平台无关”和“平台相关”分离。share平台无关的通用代码占绝大部分os操作系统相关的代码如Linux、Windows各自的实现cpuCPU架构相关的代码如x86、ARM各自的实现os_cpu操作系统与CPU组合相关的代码为什么要这样分因为JVM要跑在各种操作系统和CPU架构上但大部分逻辑比如对象分配、GC算法是通用的。把通用部分放share把平台差异部分单独抽出来这样移植到新平台时只需要改os和cpu里的代码share里的核心逻辑不用动。这是一种典型的跨平台分层设计。提示入门阶段直接看share目录就够了。os和cpu里的代码涉及大量汇编和平台细节等你把通用逻辑搞清楚再回头看否则容易被劝退。3.3share下面的“功能分区”hotspot/src/share/vm是JVM源码最核心的目录没有之一。它下面又按功能分成了多个子目录我挑最重要的几个列出来子目录功能对应JVM知识点runtime运行时核心线程管理、内存管理、JNI、反射memory内存管理堆、栈、方法区的底层实现gc_implementation垃圾收集器Serial、Parallel、CMS、G1interpreter解释器字节码解释执行compilerJIT编译器C1、C2编译器classfile类文件处理.class文件解析oops对象模型Java对象在JVM中的表示prims本地方法JNI实现、Unsafe等这张表就是你的“JVM源码导航图”。想研究GC进gc_implementation想看类加载进classfile和runtime想理解JIT进compiler。每个目录对应一个明确的JVM子系统划分得非常干净。3.4 为什么oops和memory要分开这里有个容易混淆的点oops和memory都跟内存有关为什么要分成两个目录简单说oops管的是“对象长什么样”memory管的是“内存怎么分配和回收”。oops是“Object-Oriented Programming System”的缩写里面定义的是Java对象在JVM内部的表示方式——对象头、实例数据、对齐填充这些。而memory目录里是堆的分配策略、内存屏障、卡表等更底层的机制。打个比方oops是“汽车的设计图纸”规定了一辆车由哪些部件组成memory是“停车场的管理规则”规定车怎么停、怎么挪、什么时候清走。两者配合但职责不同。4. 关键目录深挖从runtime到gc_implementation上一节给了你一张功能地图这一节挑几个最核心的目录往下钻一层让你知道每个目录里具体有什么、入门时该看哪些文件。4.1runtimeJVM的“中枢神经”hotspot/src/share/vm/runtime是我个人认为最值得先读的目录。它里面放的是JVM运行时的基础支撑代码很多其他模块都依赖它。几个关键文件thread.cpp/thread.hppJava线程与操作系统线程的映射os.cpp/os.hpp操作系统抽象层接口javaCalls.cppJava方法调用的入口reflection.cpp反射机制实现synchronizer.cpp同步与锁的实现globals.cpp全局变量定义入门建议从thread.cpp和javaCalls.cpp入手。前者帮你理解“一个Java线程在JVM里到底是什么”后者帮你理解“调用一个Java方法时JVM做了什么”。这两个问题搞清楚了后面看解释器和编译器会顺很多。4.2memory堆和栈的底层实现memory目录里最核心的文件是universe.cpp和heap.cpp。universe这个词在JVM里指的是“运行时内存空间的整体视图”包括堆、方法区、各种元数据空间。heap.cpp则是堆的具体实现。还有一个文件值得注意metaspace.cpp。JDK 8之后永久代被元空间取代元空间的管理逻辑就在这个文件里。如果你对“为什么永久代会被移除”这个问题感兴趣读这个文件比看任何博客都直接。4.3gc_implementation垃圾收集器的“家族树”这个目录下面按收集器分成了多个子目录gc_implementation/ serial/ parallel/ cms/ g1/ shared/shared里放的是各收集器共用的基类和工具其他目录各自实现具体的收集算法。入门建议先看serial因为它最简单、代码量最少把Serial收集器的完整流程读一遍再去看Parallel和G1会轻松很多。注意不同版本中GC目录的组织方式有变化新版本可能把G1相关代码移到别处或者引入新的收集器目录。读之前先确认版本。4.4interpreter和compiler执行引擎的两条路interpreter目录里是字节码解释器的实现。核心文件是bytecodeInterpreter.cpp和templateTable.cpp。前者是解释执行的主循环后者定义了每个字节码对应的操作模板。compiler目录则复杂得多它下面又分了c1和c2两个子目录分别对应C1客户端编译器和C2服务端编译器。C1编译快、优化少C2编译慢、优化激进。JVM会根据方法的“热度”决定用哪个编译器这就是“分层编译”的核心思路。入门阶段不建议直接啃compiler代码量大、优化理论多。先把interpreter搞清楚理解“字节码是怎么被一条条执行的”再去碰JIT会更有底气。5. 读源码前必须建立的三个认知目录结构本身不难难的是很多人带着错误的预期去读结果读了两天就放弃了。这一节分享三个我在读JVM源码过程中踩过的坑和总结出的认知帮你少走弯路。5.1 不要试图“从头读到尾”JVM源码不是一本小说不能从第一页翻到最后一页。它是按模块组织的模块之间有依赖关系但不存在一条“线性阅读路径”。正确的做法是带着问题读比如“一个对象创建时发生了什么”然后沿着interpreter→runtime→memory→oops这条线去追而不是按目录顺序硬啃。5.2 先读头文件再读实现文件HotSpot的.hpp头文件里通常有详细的注释解释了类的职责、关键字段的含义、以及设计意图。而.cpp实现文件里是具体的逻辑代码量大、细节多。先读头文件建立整体印象再挑关键方法读实现效率会高很多。5.3 善用“调用链”而不是“文件树”目录结构是静态的但JVM的运行是动态的。真正理解一个功能靠的是追调用链从入口函数开始一层层往下跟看它调了谁、谁又调了谁。比如追一次new Object()的完整流程你会自然地从interpreter走到runtime再走到memory这比死记目录结构有用得多。提示追调用链时建议用支持“跳转到定义”的编辑器配合grep或ripgrep搜索函数名效率比手动翻目录高一个数量级。6. 把目录结构变成自己的“源码地图”最后分享一个我自己的做法画一张自己的JVM源码地图。不是照抄官方目录树而是按“我想研究的问题”来组织。比如我想研究GC → 地图上标出gc_implementation、memory、oops我想研究类加载 → 标出classfile、runtime我想研究JIT → 标出compiler、interpreter这张地图不用很精确关键是你自己画的。画的过程就是理解目录关系的过程。我当初画了三版才觉得顺手第一版太细第二版太粗第三版才找到“按问题组织”的节奏。另外建议在源码根目录放一个NOTES.md记录你每次读源码的发现哪个文件负责什么、哪个函数是关键入口、哪个地方有坑。读JVM源码是个长期工程笔记比记忆可靠得多。等你把目录结构理顺了后面无论是读GC代码还是看JIT优化都会发现“找文件”这件事不再消耗你的精力你可以把全部注意力放在代码逻辑本身。这才是目录结构入门真正的价值——它不是知识而是工具。
阅读完成 · 觉得有帮助？
