企业官网建设流程全解析

很多人在学 JVM 的时候，都会卡在“类加载”和“内存模型”这两块。

原因很简单：这两块内容表面上都是概念，背下来并不难，难的是把它们和实际遇到的报错对上号。比如错误: 找不到或无法加载主类、Exception in thread "main" java.lang.OutOfMemoryError: Java heap space、应用频繁 Full GC 导致接口超时——这些线上问题追根溯源，最后都会回到类加载机制、字节码结构和运行时内存模型上。

所以这篇笔记我不打算把《深入理解 Java 虚拟机》那本书的内容复述一遍，而是想以“排查问题”的视角，把第三篇笔记里涉及的类加载、字节码技术和内存模型串起来讲。换句话说：报错是入口，机制是地图，字节码是显微镜。学完这一篇，你再看那些报错，应该能把“现象”和“原理”连成一条线，而不是继续靠猜。

1. 从“找不到或无法加载主类”说起：类加载机制到底在干什么

先看一个特别常见的报错。你在命令行敲了java com.example.Main，结果 JVM 直接甩给你一句：

错误: 找不到或无法加载主类 com.example.Main

很多人第一反应是“类名写错了”。但对了一半，另一半是：这个类根本就没有被 JVM 加载进去。那 JVM 为什么会加载不了一个类？这就得从类加载机制的前置流程讲起。

1.1 那条看似莫名其妙的报错，背后是七个步骤

JVM 把一个 class 文件从磁盘上“变成”堆内存里一个可用的Class对象，总共要经历七个阶段：

• 加载
• 验证
• 准备
• 解析
• 初始化
• 使用
• 卸载

其中前五个阶段是类加载机制的核心，也就是我们常说的“类加载过程”。找不到或无法加载主类这个报错，发生在第一阶段“加载”，也可以发生在“初始化”阶段的某个细节上，甚至可能发生在类已经加载进去、但静态初始化块抛了异常的时候。

很多人会把“类加载”和“类初始化”混为一谈，这是第一个需要纠正的认知。

加载阶段，JVM 要做的事情是：根据类的全限定名读取二进制字节流，把字节流转化为方法区里的运行时数据结构，然后在堆内存中生成一个Class对象作为访问入口。注意，这里说的“二进制字节流”不一定是 class 文件，它可以是 ZIP 包、网络字节流、动态代理生成的字节码，甚至可以是数据库里读出来的一段二进制。

如果你在 Eclipse 或者 IDEA 里遇到找不到或无法加载主类 org.apache.catalina.startup.Bootstrap，大概率是启动配置里主类路径写错了，或者依赖没有构建进classpath。org.apache.catalina.startup.Bootstrap是 Tomcat 的启动类，IDEA 的 Tomcat 插件本质上是启动这个类。找不到它，说明你的依赖里压根没有 Tomcat 核心库的 jar，或者 IDE 没有把依赖同步到运行配置里。

1.2 加载与验证：字节码进入 JVM 的第一道关卡

验证阶段经常被忽略，因为正常情况下我们的代码不会出问题。但字节码并不一定是你写的 Java 代码编译出来的，它可以是任何工具生成的东西——恶意构造的字节码甚至能让 JVM 崩溃。所以验证阶段做的是“安全检查”，包括文件格式验证、元数据验证、字节码验证和符号引用验证。

这里面有个值得一提的点：即使你的 Java 代码是合法的，字节码层面也可能存在 JVM 不认可的结构。比如条件分支的目标地址越界、类型转换不合法等。Java 编译器在编译时通常会生成规范的字节码，所以绝大多数人一辈子不会碰到验证阶段报错。但如果你用 ASM、Javassist 这类字节码操作框架手写字节码，那就一定要小心：生成的东西过不了验证，直接就是java.lang.VerifyError。

网上有句话叫“Class 文件是一堆严格按照规范排列的二进制流”，一点都不夸张。文件开头四个字节是魔数0xCAFEBABE，紧接着是次版本号和主版本号。主版本号决定你用的 JDK 版本：52 对应 Java 8、61 对应 Java 17。如果你用 JDK 17 编译的 class 文件放到 JDK 8 环境里跑，会报UnsupportedClassVersionError，这个我也踩过。

1.3 准备、解析与初始化：真正“活过来”的时刻

准备阶段是给类的静态变量分配内存并设置默认值的阶段。这里有一个高频面试陷阱：private static int count = 10;这条语句在准备阶段执行完，count的值是 0，不是 10。10这个真正的值要等到初始化阶段调用<clinit>方法时才被赋上去。所以面试时如果问你“静态变量默认值是什么”，别答反了。

解析阶段是把常量池里的符号引用替换为直接引用的过程。符号引用就是一组字面量，比如java/lang/System、out、println，直接引用就是内存中的指针、偏移量或者句柄。这一步很多书讲得玄乎，其实可以类比成“查通讯录”：符号引用是联系人的名字，直接引用是对方的电话号码，解析就是把名字翻译成能直接拨出去的号码。

初始化阶段才真正执行 Java 代码，也就是类构造器<clinit>方法。它会按照代码顺序执行静态变量的赋值语句和静态代码块。

那么问题来了：什么时候会触发初始化？JVM 规范里规定了六种主动引用场景，包括 new 对象、访问静态字段、调用静态方法、反射、初始化子类先初始化父类、以及作为虚拟机启动的主类（也就是main方法所在的类）。

但如果是通过子类引用父类的静态字段，子类不会初始化，只会初始化父类；定义引用类型的数组也不会触发初始化。这些点考试经常考，实际排查问题的时候也容易碰到——比如某个类的静态代码块抛异常，但你以为它根本没被用到，结果日志刷了一堆错误，就是因为某个底层类在加载链路中被主动引用了。

2. 双亲委派机制：类加载器之间的“上下级”关系

类加载的“加载”阶段，关键动作是“通过类加载器获取类的二进制字节流”。而 JVM 里默认存在三层类加载器，它们之间不是平级关系，而是一种“上级对下级委派”的父子关系。

2.1 三层类加载器与委派规则

• 启动类加载器（Bootstrap ClassLoader）：负责加载$JAVA_HOME/lib目录下 JVM 自身需要的类，比如rt.jar、java.lang.*。这个加载器在 HotSpot 里是用 C++ 实现的，Java 代码中拿不到它的引用。
• 扩展类加载器（Extension ClassLoader）：JDK 9 之前负责加载$JAVA_HOME/lib/ext目录下的类；JDK 9 之后变成了平台类加载器，负责加载一些 JDK 内部模块。
• 应用程序类加载器（Application ClassLoader）：负责加载classpath下的所有类，也就是我们写的业务代码默认由它加载。

双亲委派的规则很简单：当一个类加载器收到加载请求时，它不会自己先去加载，而是把这个请求委派给父类加载器，每一层都这么做，直到最顶层的启动类加载器。只有父加载器反馈自己无法加载时，子加载器才会尝试自己加载。

2.2 为什么要设计双亲委派：隔离与安全

这一点可以从两个角度理解。

第一是安全。如果我们可以自定义一个java.lang.String类，并且让 JVM 先用我们自定义的版本，那整个 Java 生态就乱套了。双亲委派机制保证了java.lang.*核心类一定由启动类加载器加载，用户自定义的同名类永远不会被优先使用，从源头上杜绝了核心类被篡改的问题。

第二是避免重复加载。同一个全限定名只能被加载一次，父加载器能加载的类，子加载器没必要重复加载一遍。这保证了同一个类在 JVM 中是“唯一”的。

但注意，双亲委派不是“强制”的，它只是loadClass方法的默认实现逻辑。你可以继承ClassLoader并重写loadClass方法，破坏双亲委派。最有名的场景有两个：JDBC 的ServiceLoader机制（JDK 核心类需要调用第三方数据库驱动）和 Tomcat 的 Web 应用类加载器（每个 Web 应用需要隔离不同的依赖版本）。这些属于“打破双亲委派”的经典案例，面试经常问，实际工作中你如果写自定义类加载器，也会面临同样的设计取舍。

2.3 实际工作中遇到的类加载器冲突排查

我见过的真实案例是：某个项目里同时引入了 A 库 1.0 和 B 库，B 库内部又传递依赖了 A 库 2.0。两个版本里的同一个类com.example.internal.CoreUtils都被打进了最终产物，运行时报了一堆NoSuchMethodError或者ClassCastException。

这种问题的排查思路是：

1. 用-verbose:class启动参数，JVM 会把每个类由哪个类加载器加载以及从哪个 jar 加载输出到控制台。
2. 用jmap -clstats <pid>查看某个进程的类加载器统计信息。
3. 用arthas的sc命令直接查找某个类被哪个类加载器加载。
4. 定位后，通常在构建工具里排除掉冲突的传递依赖，或者统一版本。

类加载器的问题，难的不是原理，而是“你压根没想到是类加载器的问题”。所以我的经验是：遇到NoSuchMethodError、NoClassDefFoundError、ClassCastException这类诡异报错，先默认它是依赖冲突或类加载器冲突，再考虑代码逻辑问题。

3. 字节码技术：看懂 class 文件，才算看懂 Java

很多 Java 开发者写了几年代码，没见过.class文件长什么样。这很可惜，因为字节码是连接“Java 源码”和“JVM 运行时”之间的桥梁。很多“语法糖”在源码层面看是一个样子，编译成字节码之后又是另一个样子，只有看懂字节码，才能真正理解 Java 语言背后做了什么。

3.1 class 文件结构与魔数、版本号

我之前已经提过，class 文件开头 4 个字节是0xCAFEBABE，这是 JVM 识别 class 文件的唯一凭据。你如果把一个 txt 文件改名成.class，JVM 一读就知道这不是 class 文件，直接抛ClassFormatError。

魔数后面是版本号，再往后是常量池、访问标志、字段表、方法表、属性表等结构。整个 class 文件就是一张巨型的表，里面定义了类的基本信息、字段信息、方法信息以及字节码指令。

手工解析 class 文件非常痛苦，正常不会有人这么做。我们需要的是工具：

• javap -c：反编译字节码指令，最常用。
• javap -v：输出更详细的常量池、行号表、局部变量表信息。
• javap -p：包含私有成员。
• jadx/CFR：反编译成 Java 源码，适合逆向理解别人的逻辑。

3.2 一套顺手可用的 javap 实战

我写一段极简代码：

public class Demo { public static void main(String[] args) { int a = 100; int b = 200; int c = a + b; System.out.println(c); } }

编译后执行：

javap -c Demo

你会看到类似这样的输出：

public class Demo { public static void main(java.lang.String[]); Code: 0: bipush 100 2: istore_1 3: sipush 200 6: istore_2 7: iload_1 8: iload_2 9: iadd 10: istore_3 11: getstatic #2 // Field java/lang/System.out:Ljava/io/PrintStream; 14: iload_3 15: invokevirtual #3 // Method java/io/PrintStream.println:(I)V 18: return }

这里有几个细节值得深入：

bipush 100表示把一个 byte 范围内的整数（-128 到 127）压入操作数栈。200 超出了 byte 范围，所以编译器用了sipush。如果常量更大（比如 32768 以上），指令就会变成ldc，从常量池加载。这就是为什么说“Java 里的 int 常量在字节码层面有不同的加载指令”——性能差异其实可以忽略，但面试官爱问。

istore_1表示把操作数栈顶的值存入第 1 个局部变量槽位。局部变量表的下标从 0 开始，在实例方法里，第 0 位是this。静态方法没有this，所以args占的是第 0 位。这个细节你写一个静态方法再写一个实例方法，对比一下javap输出，就一目了然。

iadd是整数加法，它从操作数栈弹出两个 int，相加后再把结果压回栈顶。理解这一点，你就知道 JVM 是基于栈的指令集架构——所有运算都在操作数栈上完成，而不是像寄存器架构那样直接在寄存器里操作。

3.3 常见字节码指令与面试考点

字节码指令一共 200 多个，全背下来不现实，但核心的几类必须眼熟：

• 加载和存储指令：iload、lload、fload、dload、aload、istore、lstore、astore。
• 运算指令：iadd、isub、imul、idiv、iinc（局部变量自增）。
• 类型转换指令：i2l、l2i、f2d等。
• 对象创建与访问指令：new、getfield、putfield、getstatic、putstatic。
• 方法调用指令：invokevirtual、invokespecial、invokestatic、invokeinterface、invokedynamic。

其中invokedynamic是 JDK 7 引入的，也是 JDK 8 中 Lambda 表达式实现的基础。你可以写一个 Lambda 表达式的代码，然后javap -c -p去看，会发现编译器生成了一个lambda$main$0之类的私有静态方法，并通过invokedynamic动态调用。理解了这一点，面试时被问到“Lambda 底层怎么实现的”，你就不只是背答案，而是真的能讲清楚。

3.4 字节码技术在工程里的实际应用

字节码技术离工程实践并不远。常见的应用场景有：

• 动态代理：JDK 动态代理基于InvocationHandler加反射，cglib 基于继承加字节码生成。
• APT 与 Lombok：Lombok 在编译期通过注解处理器生成 getter/setter。
• 热部署：Spring Boot DevTools 通过自定义类加载器实现类文件热替换。
• 性能监控：Arthas 通过字节码增强，在方法入口和出口插入监控代码，实现动态的watch、trace。

如果你对这些框架的底层原理感兴趣，建议从Javaassist或者ASM入手。ASM 上手曲线陡，但它是很多框架的真实选择；Javaassist 更简单，适合理解进阶概念。我自己第一次用 Javaassist 生成一个类并加载运行时，才真正理解“类加载器加载的是字节流”这句话的含义。

4. 运行时内存模型：六块区域与对象的一生

类加载机制解决的是“类能不能被 JVM 认识”的问题，而一旦类被加载、初始化完成，真正干活的还是运行时数据区——也就是我们常说的 JVM 内存模型。这一块是面试重灾区，也是线上 OOM 排查的知识基础。

4.1 六块内存区域划分

JVM 运行时数据区可以分成六块，按线程是否共享来分：

JDK 8 之后，方法区的实现变成了元空间（Metaspace）。和之前的永久代最大的区别是：元空间不在 JVM 堆内存里，而是使用本地内存。这就是为什么遇到OutOfMemoryError: Metaspace时，-Xmx调得再大也没用，要调-XX:MaxMetaspaceSize。

4.2 栈帧结构：局部变量表、操作数栈与动态连接

虚拟机栈对应的是“线程执行到某个时刻的方法调用链”。每次调用一个方法，JVM 就往当前线程的虚拟机栈压入一个栈帧。栈帧里面有四样东西：

• 局部变量表：存放方法参数和局部变量，单位是变量槽（Slot）。
• 操作数栈：存放计算过程中的中间结果。
• 动态连接：指向方法所属类的运行时常量池引用。
• 方法返回地址：方法执行完后回到调用位置。

有一个常见的错误认知：Java 的“基本类型变量存在栈上，对象存在堆上”。这句话严重不准确。

准确的说法是：局部变量表里的基本类型变量存的是值本身；引用类型的变量存的是对象的“引用”（指向堆中对象的地址）；对象本身一定在堆上。如果你在一个方法里new一个对象，这个对象的引用在栈帧的局部变量表里，对象实体在堆里。

由于虚拟机栈是有深度的，递归调用太深就会抛出StackOverflowError。解决办法往往不是调栈大小，而是检查递归终止条件和数据规模。

4.3 对象的一生：创建、内存布局与访问定位

一个对象从创建到被回收，大致经历这几个步骤：

1. 执行new指令，在堆上分配内存。
2. 内存分配完成后，JVM 将内存空间初始化为零值。
3. JVM 对对象头进行设置，包括 Mark Word、类元数据指针等。
4. 执行<init>方法，按构造函数和实例代码块初始化。

对象在堆中的内存布局分为三块：对象头、实例数据和对齐填充。对象头里有两个核心部分：Mark Word（存储对象自身的运行时数据，比如哈希码、GC 分代年龄、锁状态标志）和类型指针（指向类的元数据，JVM 通过它确定这个对象是哪个类的实例）。

这就是为什么面试问“一个空Object对象占多少内存”时，答案不一定是 16 字节——要分 32 位还是 64 位、是否开启指针压缩等具体情况。

关于对象访问，主流实现方式有两种：

• 句柄池：堆里单独有一块句柄池，引用先指向句柄，句柄再指向对象实例数据和类元数据。
• 直接指针：引用直接指向对象实例数据，对象里再通过类型指针访问类元数据。HotSpot 默认采用这种方式。

这也说明一个点：Java 语言规范只定义了“通过引用访问对象”，具体实现由 JVM 决定。学习时不要把所有 JVM 特性都以为是语言规范。

4.4 逃逸分析与栈上分配

提到对象分配，很多人默认“对象一定分配在堆上”。但实际上 JVM 在开启逃逸分析后（默认开启），如果对象不会被其他线程或方法外部访问，可能进行栈上分配或标量替换，对象就不一定存活在堆上。

简单例子：

public class EscapeTest { public static void main(String[] args) { long start = System.currentTimeMillis(); for (int i = 0; i < 100000000; i++) { createObject(); } System.out.println(System.currentTimeMillis() - start); } public static void createObject() { Point p = new Point(1, 2); } }

Point对象在createObject方法内部创建并返回，但返回后没用。JVM 把这部分 allocate 优化掉了，循环跑得飞快。如果关闭逃逸分析（-XX:-DoEscapeAnalysis），性能就会断崖式下降。

理解逃逸分析，不是为了炫技，而是为了建立“JVM 比你想象的聪明”的认知：很多代码层面的“优化”，JIT 编译时自己会做，你硬改成复杂写法反而阻止了优化。这也是为什么我一直建议：优先写语义清晰的代码，过早的“性能优化”往往适得其反。

5. 内存问题排查与 JVM 调优工具实战

理论讲完，接下来进入最实际的部分：线上遇到 OOM、GC 频繁、CPU 飙高，怎么一步步定位。

5.1 OOM 的几种典型场景

1. java.lang.OutOfMemoryError: Java heap space：堆内存不足。典型原因是对象太多、存在大对象、或者内存泄漏。
2. java.lang.OutOfMemoryError: GC overhead limit exceeded：GC 回收效率极低，连续多次 GC 释放的内存不到 2%，JVM 直接心态崩了。
3. java.lang.OutOfMemoryError: Metaspace：元空间不足。通常因为动态生成大量类（CGLIB 代理、热部署）。
4. java.lang.OutOfMemoryError: unable to create new native thread：操作系统的线程数达到上限，这不是 JVM 堆的问题，而是系统资源耗尽。

所以一看到 OOM，不要立刻调-Xmx。先看是哪一种 OOM，再对症下药。

5.2 用一整套工具定位问题的完整链路

以一个典型的“测试环境偶发接口超时，日志出现 heap space”为例，完整链路如下：

第一步，jps确认进程号。

jps -l

输出类似：

30560 /Users/xxx/Demo/TestApplication.jar

记下 PID，假设是 30560。

第二步，jstat看 GC 情况。

jstat -gcutil 30560 1000 10

这个命令每秒输出一次 GC 统计，共输出 10 次。重点关注FGC（Full GC 次数）、FGCT（Full GC 总耗时）、O（老年代使用率）。如果老年代不断上涨且 Full GC 后下降不明显，基本可以判断有对象堆在里面出不去。

第三步，jmap导出堆快照。

jmap -dump:format=b,file=/tmp/heap.hprof 30560

堆快照文件比较大，生产环境小心使用，建议在低峰期操作，或者干脆在启动参数里指定-XX:+HeapDumpOnOutOfMemoryError，让 JVM 在 OOM 时自动生成快照。

第四步，用 MAT 或 VisualVM 分析快照。MAT 打开后先看Leak Suspects报告，它会自动帮你找出占用堆内存最大的对象和引用链。

5.3 jstack 排查线程问题与 arthas 动态观测

如果问题是线程阻塞、死锁或者 CPU 飙高，jstack是首选。

jstack 30560 > thread_dump.txt

在 thread_dump.txt 里搜索deadlock，如果存在死锁，JVM 会直接打印出死锁的线程和锁的持有方。如果线程大量卡在WAITING状态，多半是线程池配置不合理或某个任务长期占用了工作线程。

Arthas 是我用过最顺手的动态排查工具，推荐几个高频命令：

• dashboard：实时查看线程、内存、GC 概况。
• thread -n 3：列出 CPU 占用前三的线程，并显示栈信息。
• watch com.example.Service methodName returnObj：动态查看方法入参和返回值。
• trace：追踪方法内部调用耗时分布。

有了 Arthas，很多时候都不需要重启服务，直接在运行中的应用上做诊断，真的能救命。

5.4 日常预防 OOM 的开发层建议

排查很重要，但更重要的还是预防。以我自己的经验，开发阶段能做的事包括：

1. 在 IDEA 里调大 JVM 运行内存，防止开发测试时 OOM。比如：

   • Help -> Edit Custom VM Options里配置 IDEA 自身内存。
   • 运行配置的VM options里给业务项目分配合理堆内存，比如-Xms256m -Xmx1024m。

2. 注意集合类使用。静态集合是内存泄漏重灾区，比如static List<Object> CACHE = new ArrayList<>()只增不减，时间一长必然 OOM。

3. 小心大对象和大数组。比如一次性把几十 MB 的日志读到内存里解析，堆很容易被打满。能流式处理就流式处理。

4. 关注线程池。每个线程默认栈大小是 1MB（-Xss），200 个线程就是 200MB 内存，不属于堆，但也是进程级资源。线程数设置过大会直接耗尽系统内存。

5. 合理配置元空间大小。如果项目里用了很多动态代理和 CGLIB，建议显式设置-XX:MaxMetaspaceSize，避免元空间无限扩张。

在这个主题上我还想分享的一点

这套笔记写下来，我的感受是：JVM 的知识不是靠背诵掌握的，而是靠“遇到问题、查原理、回到代码、验证结论”这个循环慢慢积累的。

就拿类加载和内存模型来说，你可以在写代码时留意：某个类的静态代码块什么时候执行？一个对象到底占多少内存？为什么调大堆内存反而让 Full GC 更久？带着这些问题去查书、去看实际日志，比单纯刷十遍面试题都管用。

如果你刚开始接触 JVM，我建议按这个顺序来：先把类加载机制和运行时数据区的划分搞熟，再用javap反编译几个简单类建立字节码的直觉，最后把工具链（jps、jstat、jmap、jstack、Arthas）在日常开发里用起来。三者串起来之后，再看那些 JVM 调优文章，你会发现过去看不懂的参数和理论，突然就说得通了。

下一篇笔记我会继续整理垃圾回收器选型和 GC 日志分析。到时候这一篇里的“内存区域划分”会成为很多结论的底层依据，建议先把这篇里的基础概念消化透。