java命令是JVM启动的守门人：先解析参数、定位并加载jvm.dll/libjvm.so，再调用JNI_CreateJavaVM初始化虚拟机，最后通过JavaMain执行main方法；跳过该流程则JVM无法识别为合法Java程序。
OpenJDK 的 JVM 执行 Java 程序不是“直接运行源码”，而是严格依赖 java 命令触发一整套启动链：从 Launcher 解析参数，到加载 jvm.dll（Windows）或 libjvm.so（Linux/macOS），再到调用 JNI_CreateJavaVM 创建虚拟机实例，最后定位并执行 main 方法。跳过这个流程，比如试图手动加载字节码或绕过类加载器，JVM 不会识别为合法 Java 程序。
java 命令到底做了什么
执行 java HelloWorld 时，真正干活的是 java 可执行文件（即 Java Launcher），它位于 JDK 的 bin/ 目录下。这个程序本身不解释字节码，只负责“搭桥”：
- 调用
JLI_Launch函数（源码在/src/java.base/share/native/libjli/java.c），解析-Xmx、-cp、主类名等参数 - 根据
JAVA_HOME和系统架构，定位并动态加载 JVM 共享库（如jvm.dll） - 通过
JNI_GetDefaultJavaVMInitArgs和JNI_CreateJavaVM初始化 JVM 实例 - 调用
ContinueInNewThread启动新线程，在该线程中执行JavaMain
也就是说，java 命令是 JVM 的“守门人”，不是“执行者”。你不能删掉它，只留 jvm.dll 就让程序跑起来。
类加载失败的典型错误和定位点
最常见的 ClassNotFoundException 或 NoClassDefFoundError 往往卡在类加载阶段，但原因可能分散在不同环节：
-
Bootstrap ClassLoader找不到rt.jar或modules（Java 9+）——检查JRE_HOME是否指向正确 JDK/JRE 目录 -
AppClassLoader加载主类失败——确认-cp或CLASSPATH包含了HelloWorld.class所在目录，且路径中不含.class后缀 - 类名与文件名不一致（如文件叫
helloworld.java，类声明为public class HelloWorld）——JVM 会拒绝加载，报BadSourceFile类错误 - 使用模块路径（
--module-path）但未声明module-info.java，或主类不在模块导出范围内——Java 11+ 中这类问题不会报错，但直接静默失败
JVM 启动后真正执行 main 的位置
一旦 JVM 实例创建成功，控制权就交给 HotSpot 内部的 JavaCalls::call_static 流程。关键步骤如下：
-
JavaMain函数（/src/share/bin/java.c）调用InitializeJVM完成初始化后，进入LoadMainClass -
LoadMainClass使用FindClassFromBootLoader在 bootstrap class path 查找主类；若失败，再委托给AppClassLoader - 找到类后，调用
GetStaticMethodID获取名为main、签名是([Ljava/lang/String;)V的静态方法 - 最终通过
CallStaticVoidMethod触发执行——此时才真正开始运行你的字节码
注意：main 方法必须是 public static void，且参数类型必须是 String[]；写成 String... 或 List 都会导致 NoSuchMethodError，因为 JVM 只认固定签名。
为什么 javac 编译完还不能直接执行
因为 javac 只生成合规字节码，不参与任何 JVM 生命周期管理。它甚至不知道你打算用哪个版本的 JVM 运行——javac -source 8 -target 11 编译出的 class 文件，可以被 Java 17 的 JVM 加载（只要没用高版本 API），但能否运行取决于运行时类路径、模块图和 JVM 自身支持的字节码版本。
一个容易被忽略的细节：java 命令启动时默认启用双亲委派，而自定义类加载器若破坏该模型（比如重写 loadClass 并跳过 super.loadClass），可能导致 java.lang.String 被重复加载，引发 LinkageError。这不是配置问题，是 JVM 架构级约束。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
