JVM主线程的诞生：从操作系统线程到Java执行起点的完整链路

先抛一个有点反直觉的结论：你写的 public static void main(String[] args)，并不是 JVM 主线程的起点。真正的起点，比你想象中要早得多——早到操作系统还在加载可执行文件、代码还没碰到任何 Java 字节码的时候。

很多人学 JVM，张嘴就是内存模型、垃圾回收器、类加载机制，但很少有人去追一个问题：那个叫 main 的线程，到底是怎么从无到有，一步步走进我们熟悉的 Java 世界的？这个问题一旦追到底，你会发现 JVM 的“创世过程”其实比大部分八股文精彩得多，而且很多 JVM 调优、异常排查、面试题里的“为什么”，都能从这里找到根源。

这篇文章我就顺着 HotSpot VM 的真实启动链路，把主线程的诞生过程彻底拆开讲一遍。不讲虚的，全部落到源码逻辑和实际操作上，顺便把启动过程中那些最容易被忽略、又最容易出问题的细节都点出来。无论你是准备面试、排查线上问题，还是单纯想搞懂 JVM 到底是怎么“活过来”的，这篇都值得认真读完。

1. 在进入 main 方法之前：一个 C 进程的觉醒

首先要打破一个根深蒂固的误解：java 命令本身不是一个“JVM 程序”，它是一个用 C/C++ 写的普通可执行文件。你在命令行敲下 java HelloWorld 的那一刻，操作系统压根不知道世界上有“Java”这件事，它只知道自己创建了一个新的进程，入口函数是某个可执行文件里的 main 函数。

1.1 java 命令的真面目：一个启动器

这个可执行文件就是 JVM 的启动器（Launcher），在 JDK 里对应着 jdk/src/java.base/share/native/libjli/java.c 这份源码编译出来的产物。在 Linux 上你执行 which java，通常指向 /usr/bin/java，这往往是一个软链接，最终指向 JDK 安装目录 bin/java。

这个启动器的核心任务拆开看只有三件事：

• 解析命令行参数，包括 -X、-XX 开头的所有 JVM 参数，找出要执行的主类名或 jar 包路径。
• 根据参数确定要加载哪个 libjvm.so（Linux/macOS）或 jvm.dll（Windows）动态库，这个是 JVM 真正的本体。
• 通过动态链接的方式，找到 JVM 暴露给外界的入口函数 JNI_CreateJavaVM，然后调用它。

这里有一点值得注意：启动器进程被创建的时候，操作系统会同时给它分配一条线程，这条线程就是整个进程的第一个线程，也是后续一切故事的起点。在 Linux 上，这条线程的线程 ID 等于进程 ID（PID），它就是我们常说的“主线程”。但这个阶段，它还只是一条纯粹的 native 线程，跟 Java 没有任何关系。

1.2 JNI_CreateJavaVM：连接两个世界的接口

JNI_CreateJavaVM 是整个 JVM 启动过程中最关键的一个函数。它属于 JNI（Java Native Interface）的一部分，是 JVM 对外开放的标准接口。HotSpot 里这一层封装在 jni.cpp，如果你有源码，可以直接搜这个名字。

从启动器的视角看，它只是调了一个函数，然后等待返回值。但这个函数内部一旦启动，就再也不会回头了——它会完成整个 JVM 的“创世”，并在返回时让当前这条线程摇身一变，成为 JVM 里的主线程。

用一个不太严谨但很形象的比喻：启动器是助产士，libjvm.so 是孕育婴儿的子宫，而 JNI_CreateJavaVM 就是那声啼哭。整个 JVM 的诞生，都是从这一声啼哭开始的。

这里补充一个很多文章不会讲的细节：JNI_CreateJavaVM 只能被调用一次。如果用 JNI 方式在一个进程里尝试创建第二个 JVM，会直接返回错误。这是因为 JVM 内部有大量的全局状态和静态结构，设计之初就没打算支持多实例共存。这也是为什么很多 Java 进程内嵌其他语言时，凡是试图“再启动一个 JVM”的方案，基本都会失败。

2. 从 OS 线程到 JavaThread：主线程对象的诞生过程

当控制权从启动器交到 JNI_CreateJavaVM 之后，HotSpot 内部会经历一段非常长的初始化过程。但对“主线程”这个概念来说，真正重要的转折点在于：JVM 会把当前正在执行的那条 native 线程，包装成一个 JavaThread 对象。

2.1 JavaThread 对象：JVM 眼中的线程

在 HotSpot 里，每一个 Java 线程都对应一个 JavaThread 实例，这是 C++ 层的对象，不是 Java 层的 java.lang.Thread。两者之间有对应关系：Java 层 Thread 对象的 nativeThread 字段会指向 C++ 层的 JavaThread 指针。

在 Threads::create_vm 这段初始化流程中，JVM 会执行类似这样的逻辑：

1. 创建一个 JavaThread 对象。
2. 将当前 native 线程与该 JavaThread 对象绑定。
3. 设置这个线程的名字为 "main"。
4. 调用 Threads::add 把它加入 JVM 的全局线程列表。
5. 初始化线程状态，使它进入可运行状态。

这一步的意义在于：从此以后，JVM 的线程管理系统有了第一个成员。它既不是 VMThread（JVM 内部管理线程），也不是后面那些 GC Thread、Compiler Thread，而是真正承载 Java 主逻辑的那条线程。

2.2 为什么必须是“当前线程”成为主线程，而不是另起一条线程？

这是很多人容易产生疑问的地方。为什么 JNI_CreateJavaVM 不干脆内部 pthread_create 一条新线程去当主线程？

答案其实很朴素：因为在操作系统的进程模型里，进程的入口线程承担着进程“根”的角色。如果 JVM 另起线程而放弃当前线程，就会面临一个问题——谁来等待主线程结束？进程退出时的返回值谁来设置？信号处理怎么办？

更重要的是，JVM 的 main 方法语义是：执行 main 方法的线程，就是主线程。这与操作系统进程的主线程天然对应。如果 JVM 重新造一条线程，那启动器调用 JNI_CreateJavaVM 的那条线程就成了一个“旁观者”，而 Java 世界里的“主线程”却是一个真正的子线程，这会在信号处理、进程退出、线程组归属等很多地方造成难以预料的麻烦。

所以 HotSpot 的选择是：直接让创建 JVM 的那条线程“转正”，继续往后执行 Java 代码。这样从操作系统进程到 JVM 主线程是一条完整的调用链，没有任何断点。

2.3 OSThread 与 ThreadLocal 的绑定关系

这里还有一个容易被忽略的实现细节：JavaThread 对象内部还有一个 OSThread 成员，它负责封装操作系统层面的线程句柄。在 Linux 上，OSThread 里保存了 pthread_t、线程状态标志、互斥锁等底层资源。

同时，为了能够快速从 native 代码拿到当前线程对应的 JavaThread 对象，HotSpot 使用了线程局部存储（Thread Local Storage，TLS）。在 Linux 上通常通过 __thread 关键字或者 pthread_getspecific 实现。这个 TLS 指针在 JNI_CreateJavaVM 的初始化过程中被设置，之后无论 JVM 内部哪个模块想获取当前 JavaThread，直接读这个 TLS 变量即可。

这个设计关系到后续所有同步操作、GC 安全点检查、线程状态变更，是整个 JVM 并发体系的基石。没有这一步，后面的线程调度、锁膨胀、偏向撤销等机制全都无从谈起。

3. 创世前的准备：主线程等待的 JVM 基础设施

主线程对象虽然已经诞生了，但它现在还不能执行任何 Java 代码。原因很简单：Java 世界还没搭建好。就像一个婴儿已经出生，但周围的环境还没布置好，还不能开始生活。

3.1 内存系统：堆、元空间与代码缓存

JVM 启动过程中，必须先完成内存系统的一系列初始化。具体来说：

• 堆内存：根据 -Xms、-Xmx 参数划分年轻代和老年代，如果是 G1 收集器还要初始化 Region 结构。
• 元空间（Metaspace）：用于存放类元数据，在 JDK 8 之后取代了永久代。
• 代码缓存（CodeCache）：用于存放 JIT 编译后的机器码。

主线程在执行第一个 Java 方法之前，这些结构必须全部就绪。否则，就连最简单的 new Object() 都无法完成内存分配。

这里有个有意思的点：如果你在启动参数里把 -Xmx 设得很大，JVM 启动时并不会真的把所有内存都申请回来，而是只提交一部分，其余部分保留在虚拟地址空间里。这与 -Xms 有关，-Xms 决定启动时提交多少，-Xmx 决定上限。这也是为什么线上环境推荐把 -Xms 和 -Xmx 设成一样的值——避免运行期堆扩容带来的性能抖动。

3.2 类加载器体系：三件套的初始化

在 Java 代码运行之前，类加载器体系也必须提前就位。启动类加载器（Bootstrap ClassLoader）由 C++ 实现，负责加载 java.base 等核心模块；平台类加载器（Platform ClassLoader）和应用类加载器（App ClassLoader）是 Java 层实现，但它们自身的初始化是用 native 方式引导的。

也就是说，为了加载第一个 Java 类，JVM 必须先借助 native 手段把类加载器体系“启动”起来。这个先后顺序很微妙：类加载器本身是 Java 对象，但它的初始化却发生在 Java 世界完全可用之前。HotSpot 是通过在 C++ 层手动调用 java_lang_ClassLoader::create_class_loader 这类内部函数，逐步搭起三个类加载器的骨架。

3.3 执行引擎：解释器和 JIT 编译器的就位

主线程执行 Java 代码，最终需要执行引擎。HotSpot 的执行引擎分为两部分：

• 模板解释器：启动时生成一堆机器码模板，用于解释执行字节码。
• C1/C2 编译器：运行时将热点方法编译成本地机器码。

主线程在启动初期执行 main 方法时，几乎都是走解释执行模式。只有当一个方法被调用足够多次，达到热词里提到的 -XX:CompileThreshold 阈值之后，JIT 编译器才会介入。

这个参数值得多说两句。-XX:CompileThreshold 默认值在 C1 模式下通常是 1500，C2 模式下是 10000。它表示一个方法被解释执行的次数达到该值后，才会触发 JIT 编译。很多人以为这个阈值越小启动越快，其实不一定——编译本身也要消耗 CPU，而且编译后的代码还需要经过优化。实际调优时要看业务的负载特征，不能盲目调参。

3.4 VMThread：JVM 的后台指挥中枢

还有一个特殊线程必须和主线程同期创建，那就是 VMThread。它不执行任何 Java 方法，而是专门处理 JVM 内部的 VM Operation，比如 GC 的 Stop-The-World 阶段、内存回收的全局操作、类卸载等。主线程在创建 Java 对象的全过程中，一旦触发 GC，就必须和 VMThread 协作，进入安全点，等待 GC 完成。

主线程与 VMThread 之间的协作方式，就是 JVM 中极其重要的安全点（Safepoint）机制。主线程在解释执行字节码时，会定期检查安全点标志。当 GC 需要 STW 时，VMThread 会设置这个标志，所有执行线程（包括主线程）在下一次安全点检查时主动挂起。

这一段如果展开写，每一部分都是一大本书。但如果你把视角拉高，会发现核心逻辑非常简单：主线程的孕育，必须等整个 JVM 的神经系统、循环系统、消化系统全部落成之后，才算完成。

4. 第一个 Java 帧：主线程调用 main 方法的完整链路

所有初始化完成后，控制权重新回到启动器代码。此时 JNI_CreateJavaVM 返回，启动器拿到了一个 JVM 句柄。接下来它要做的事情，就是让主线程真正进入 Java 世界。

4.1 JavaMain：启动器的主心骨

启动器接下来调用 JavaMain（在 java.c 中），这个函数负责四件事：

• 通过 JNI 找到主类。
• 获取主类的静态 main 方法。
• 校验 main 方法的签名是否为 ([Ljava/lang/String;)V。
• 调用 CallStaticVoidMethod 执行该方法。

这里有一个非常关键的细节：从启动器调用 JNI_CreateJavaVM 开始，到 JavaMain 里调用 CallStaticVoidMethod 为止，整个过程都是同一条线程（就是操作系统创建进程时的那个主线程）在执行。中间没有换线程、没有重新创建线程。

4.2 主类的加载与 main 方法的解析

找到主类的过程，表面上是 JNI 的 FindClass，背后则是类加载机制在起作用。启动器会调用 JNI_FindClass 或者通过 AppClassLoader 加载主类。这个阶段会触发类的加载、连接（验证、准备、解析）、初始化三步曲。

类初始化阶段很关键：执行 <clinit> 方法，也就是静态变量赋值和静态代码块。这些静态代码的执行线程，就是主线程。所以如果你在某个类的静态块里写了一个耗时操作，直接受影响的就是主线程的启动时间。

获取 main 方法 ID 用的是 JNI_GetStaticMethodID，因为它是一个静态方法。如果你写错了方法签名（比如少写 String[] 参数），这一步就会抛 NoSuchMethodError。这也是为什么 JVM 要求主方法必须是 public static void main(String[] args)，少一个修饰符都不行——因为启动器找方法时就是按这个签名去找的。

4.3 CallStaticVoidMethod：从 native 进入 Java 的关键一跃

CallStaticVoidMethod 是 JNI 的调用函数，它内部会完成从 C++ 到 Java 的栈帧切换。这是整个 JVM 启动过程中最具仪式感的一步：

1. 创建一个 Java 栈帧，对应 main 方法。
2. 将参数数组放入栈帧的局部变量区。
3. 设置程序计数器，指向 main 方法的第一个字节码指令。
4. 调用执行引擎，开始逐条解释执行字节码。

这一刻，主线程才真正成了“Java 主线程”。它不再只是 C++ 层的一个 JavaThread 对象，而是在 Java 虚拟机栈上有了自己的第一帧。jstack 里看到的 "main" 线程，就是从这里开始的。

4.4 为什么第一个方法走的是解释执行？

HotSpot 默认情况下不会在启动阶段预编译 main 方法，除非你开了 -Xcomp 强制编译模式。这是因为 main 方法通常只执行一次，不值得为它做昂贵的 JIT 编译。解释执行足够快，而且不会消耗额外的 CPU 时间。

但要注意：main 方法虽然走解释执行，它调用的热点方法很快就会触发 JIT 编译。比如 main 里有个循环调用了 100000 次 Math.sqrt，那么 Math.sqrt 会被编译成机器码，后续调用都走编译后的代码。这个“解释 -> 热点检测 -> 编译 -> 替代”的过程，就是 JIT 的工作方式。

这里就体现出 -XX:CompileThreshold 的实战意义了。如果你的服务启动后有大量一次性逻辑（比如加载配置、预热缓存、初始化连接池），这些逻辑如果都走解释执行，性能会比编译后差不少。所以很多高并发服务的启动阶段会有明显的 CPU 飙高现象——那不是坏事，是 JIT 在干活。

5. 主线程的“人设”：栈、命名与 jstack 里的样子

主线程进入 Java 世界后，它并不是一个抽象概念，而是在 JVM 里有明确的、可观测的特征。这些特征如果你没搞懂，排查问题时会多走很多弯路。

5.1 线程名 “main” 的来源

主线程的名字就是简单的 "main"。这个名字不是 Java 层 Thread.currentThread().getName() 默认随机生成的，而是在 C++ 层创建 JavaThread 对象时就被指定了。等你通过 new Thread() 创建子线程时，名字才会是 "Thread-0"、"Thread-1" 这种自动编号。

Java 层的 Thread 对象是在 Thread.currentThread() 第一次被调用时，才由 JVM 内部从 JavaThread 包装过来的。所以严格来说，C++ 层的 JavaThread 是主线程的“本尊”，Java 层的 Thread 对象只是它的一个 JNI 化视角。

5.2 主线程的栈大小与 -Xss

主线程的 Java 虚拟机栈大小由 -Xss 参数控制，默认值取决于操作系统和 JVM 版本。在 Linux x64 上，HotSpot 的默认值通常是 1MB。这个值决定了主线程能嵌套调用多深的方法。

如果你在 main 里写一个无限递归，会抛 StackOverflowError，而不是 OutOfMemoryError。这两者的区别很明确：StackOverflowError 是栈空间耗尽，OutOfMemoryError 是堆或其他内存区域耗尽。

这里有个实战经验：-Xss 不是越大越好。栈设置太大，会导致系统能创建的线程数变少，因为每个线程的栈空间都需要预留虚拟内存地址。特别是多线程服务，如果每个线程栈 2MB，那 1000 个线程就需要 2GB 的虚拟地址空间；虽然物理内存是按需提交的，但地址空间是直接消耗的。所以调 -Xss 前，一定先算清楚线程数量和内存预算。

5.3 jstack 视角下的主线程

当你执行 jstack <pid>，输出里最开头的线程通常就是主线程，长这样：

code复制"main" #1 prio=5 os_prio=0 cpu=123.45ms elapsed=789.01s tid=0x00007f... nid=0x1234 runnable [0x00007f...]
   java.lang.Thread.State: RUNNABLE
        at com.example.HelloWorld.main(HelloWorld.java:5)

这里有几个信息值得关注：

• #1 表示它是 JVM 里的第 1 个线程。
• tid 是 JVM 内部的线程 ID，nid 是操作系统线程 ID。
• runnable 表示它正在执行。
• 位置信息显示它正在执行 HelloWorld.main 的第 5 行。

如果主线程卡住了，jstack 里会明确显示它在哪个方法上阻塞。比如等待锁时会显示 BLOCKED，调用 Thread.sleep 时显示 TIMED_WAITING，调用 Object.wait 时显示 WAITING。学会看这几个状态，基本就能定位大部分主线程问题。

5.4 主线程的 daemon 状态

JVM 里线程分两类：daemon 线程和非 daemon 线程。主线程是非 daemon 的，这是 JVM 设计上的必然要求。因为 JVM 退出的判定标准是：所有非 daemon 线程都结束。如果主线程是 daemon，那它随时可能被 JVM 强行结束，main 方法就跑不完了。

所以面试里如果问“main 线程是 daemon 吗”，答案一定是“不是”。它必须是非 daemon 的，否则整个 JVM 的启动逻辑就会自相矛盾。

5.5 主线程与子线程的区别

用一张表简单对比：

6. 当 main 返回之后：主线程与 JVM 的告别流程

主线程执行完 main 方法的最后一条语句后，故事并没有立刻结束。这一刻，主线程会经历一个微妙的“退场”阶段。

6.1 main 返回 vs System.exit()

很多人在面试时会被问到：main 方法执行完，JVM 一定会退出吗？答案是不一定。

• 如果除了主线程之外，还有其他非 daemon 线程在运行，JVM 会继续运行，直到所有非 daemon 线程结束。
• 如果所有非 daemon 线程都已经结束，JVM 会启动退出流程。

这里就有一个经典场景：main 方法里启动了一个线程池，但没有调用 shutdown，然后 main 返回了。如果线程池里的线程是非 daemon 的，JVM 会一直等待线程池里的活跃线程结束，进程不会退出。很多初学者在这个坑里跌过。

而 System.exit(n) 是强制终止 JVM。它会立即启动 JVM 关闭流程，无论当前还有多少非 daemon 线程在运行。所以如果业务上想在 main 返回前强制退出，可以用 System.exit，否则就会出现“明明 main 执行完了，进程还挂着”的现象。

6.2 主线程退出时的 JVM shutdown 流程

当主线程触发 JVM 退出时，JVM 会执行一套固定的关闭步骤：

1. 启动所有注册的 shutdown hooks（通过 Runtime.addShutdownHook 注册的线程）。
2. 若启用了 -Xrs 参数，则跳过部分关闭流程。
3. 停止所有非 daemon 线程（实际上是杀死 JVM 进程，而不是优雅地中断线程）。
4. 调用 JNI 的 DestroyJavaVM 释放 JVM 资源。
5. 进程退出，返回退出码。

这里有个常见的坑：shutdown hooks 里不允许做太多耗时操作，否则 JVM 退出会卡住。HotSpot 对 shutdown hooks 的执行时长没有硬性限制，但如果你在里面写了网络请求、数据库操作、长循环，线上服务在重启、发布、扩容时就会表现出“老半天退不掉”，严重影响发布效率。

另一个坑：在 shutdown hook 里调用了已经被停止的日志系统，或者依赖的子线程已经被中断，就会抛异常。这些异常默认是被吞掉的，你会看到一个奇怪的“小尾巴”：进程退出了，但日志里多了几行莫名其妙的报错。

6.3 主线程结束后，JVM 为什么还活着？

回到之前那个线程池场景，如果 main 返回后，线程池里的线程还活着，jstack 看它们的名字通常是 pool-1-thread-1，状态是 WAITING 或 TIMED_WAITING，因为线程池里的空闲线程在等任务。这些线程默认继承了创建它们的 main 线程的非 daemon 属性，所以 JVM 不会退出。

要解决这个问题，有两个思路：

• 在 main 方法末尾调用线程池的 shutdown()，让线程池在任务处理完后自然关闭。
• 把线程池线程设置为 daemon，比如通过自定义 ThreadFactory 设置 setDaemon(true)。

第二种方案要谨慎：如果线程池线程是 daemon 的，但 JVM 在 main 返回后直接退出了，线程池里还没执行完的任务就会被打断，可能造成数据不一致。

7. 主线程相关的实战排查与面试高频考点

这部分我把这些年实际排查线上问题、带团队面试时积累的经验，挑最干的写出来。

7.1 面试题的几个标准答案

围绕主线程，面试官翻来覆去问的无非就这几个：

• main 线程是 JVM 的第几个线程？ 如果从 pure Java 线程角度看，它确实是第一个；但 JVM 内部其实还有 VMThread、GC 线程等在 main 之前或同期创建。所以严谨的说法是：主线程是第一个执行 Java 字节码的线程，但是否是 JVM 创建的“第一个线程”要看从什么维度统计。
• main 方法执行完后，JVM 一定退出吗？ 不一定，看是否存在非 daemon 线程。
• 如何强制让进程退出？ System.exit(n)、Runtime.halt(n)。前者会执行 shutdown hooks，后者直接终止进程不执行任何清理。
• 主线程能被 stop 吗？ 不能通过 Thread.stop() 从外部强行停止，官方早已标记为不安全。强行停止可能让对象停留在不一致的状态。

7.2 实战定位：主线程卡死或假死

线上遇到接口不响应、服务“看起来没死但什么都不干”，第一步就是 jstack 打线程快照。主线程如果卡住，jstack 里会有非常明确的线索：

• 卡在 FutureTask.get() 等待子任务结果，状态是 WAITING。
• 卡在 ReentrantLock.lock() 等待锁，状态是 BLOCKED。
• 卡在 Thread.sleep()，状态是 TIMED_WAITING。
• 卡在某个网络连接的 SocketInputStream.read，状态是 RUNNABLE 但其实在等 IO。

这里有个容易误判的点：等待 IO 时，Java 线程状态依然是 RUNNABLE，而不是 WAITING。因为 JVM 无法区分“在 CPU 上跑”和“在系统调用里睡眠”，只要没走 Object.wait 或 LockSupport.park，线程状态就是 RUNNABLE。所以看到 RUNNABLE 不等于真的在消耗 CPU，还需要结合 CPU 使用率来判断。

7.3 Docker 容器里 JVM 异常重启，日志去哪查？

容器环境里 JVM 进程异常退出，和物理机不一样。进程退出后，容器本身可能被编排系统自动重启。这时你需要看的是：

• 容器内 JVM 的 stdout 和 stderr 输出，通常被 Docker 的 JSON-file logging driver 捕获，用 docker logs <container> 查看。
• JVM 如果发生致命错误（比如 SIGSEGV、SIGBUS），会在工作目录下生成 hs_err_pid<pid>.log。但容器一旦删除，这个文件也就没了。所以在容器里跑 Java 服务，强烈建议在启动参数里加上 -XX:ErrorFile=/logs/hs_err_%p.log，把错误日志重定向到挂载卷里。
• 如果配置了 -XX:+HeapDumpOnOutOfMemoryError，堆转储文件也一样，一定要指定到持久化目录，否则 OOM 后容器一重启，崩溃现场全没了。

这里我强烈建议容器环境至少加这几个参数：

code复制-XX:+HeapDumpOnOutOfMemoryError
-XX:HeapDumpPath=/logs/heapdump.hprof
-XX:+ExitOnOutOfMemoryError
-XX:ErrorFile=/logs/hs_err_%p.log

-XX:+ExitOnOutOfMemoryError 的作用是：一旦发生 OOM，JVM 立即退出，而不是继续硬撑。这对于容器环境尤其有用——与其让一个内存已经耗尽的 JVM 半死不活地维持假活状态，不如直接退出，让编排系统拉起一个新实例。

7.4 JVM 参数 -XX:CompileThreshold 在主线程场景的体现

关于 JIT 和主线程的关系，有一个实战中很有意思的现象：应用启动阶段，主线程调用的初始化方法可能会被 JIT 编译。如果你在启动参数里调低了 -XX:CompileThreshold，理论上编译触发得更早，但代价是更多的方法会被“过早”编译，可能编译了之后实际只用一次，浪费 CPU。

反过来调高阈值，启动阶段更平静，但关键路径上的热点方法更晚获得机器码，启动后初期的响应时间可能偏高。所以这个参数在“启动性能”和“稳定期性能”之间是一个权衡。现代 JDK 已经引入了分层编译（Tiered Compilation），配合 -XX:TieredStopAtLevel 等参数，能更精细地控制编译层级。但在没有压测数据之前，不要随便调这两个参数。

7.5 主线程的 StackOverflowError 排查

如果你看到一个报错发生在主线程，且堆栈里同一个类名反复出现几百行，基本可以确定是递归调用太深。排查时不要只盯着异常栈，要往上找“最底部重复的那个方法”，通常就是递归入口。

实际工作中我遇到过一种隐蔽情况：递归方法长得很正常，但每层递归都创建了局部对象，导致每一栈帧占用的空间比预期大得多，原本够 10000 层递归的栈，结果 3000 层就溢出了。这种情况调整 -Xss 可以缓解，但根本解法是优化递归逻辑，比如改写成循环、减少每层栈帧的局部变量数量。

另一个隐蔽情况是：类初始化时出现循环依赖。类 A 的 <clinit> 引用了类 B，类 B 的 <clinit> 又引用类 A，最终可能导致初始化死锁，主线程卡在 ClassLoader.loadClass 上，而且 jstack 里看不出来，只能看到主线程停在某个静态初始化相关的方法上。遇到这种问题，优先去检查静态块和静态变量的初始化顺序。

写在最后：主线程诞生的本质到底是什么

如果你把这篇文章从头读到尾，应该能形成一个相对完整的画面：JVM 主线程的诞生，本质上是操作系统线程被 JVM“招安”的过程。它不需要创建一条全新的线程，而是把进程的主线程从 native 世界一步步带进 Java 世界，让它成为第一个执行 Java 字节码的线程。

这个过程中，真正让 JVM 变成 JVM 的，是那套庞大的基础设施：内存管理系统、类加载系统、执行引擎、线程管理系统、安全点机制。主线程只是在这一切就绪后，被赋予了“开始执行 main 方法”这个使命。

我自己在刚开始学 JVM 时，也走过不少弯路——总是急着看 G1 的 Region 划分、CMS 的并发标记，结果连“主线程是怎么来的”都没搞透。后来在排查一个启动初始化死锁问题时，被迫把 JNI_CreateJavaVM 到 main 方法执行的整条链路完整走了一遍，才发现很多面试题其实都是从这里衍生出来的。

如果你也想进一步验证这些内容，最直接的方式是下载 OpenJDK 源码，搜 java.c、jni.cpp、Threads::create_vm 这几个关键词，跟着断点走一遍。读代码的过程可能会有点枯燥，但当你亲眼看到主线程在 native 代码里完成了从普通线程到 Java 线程的身份转换，那种“原来如此”的感觉，是任何二手文章都给不了的。