jvm是java跨平台能力的唯一执行载体，通过各平台兼容规范的实现（如jvm.dll、libjvm.so）统一解释字节码；.class文件可跨平台运行的前提是目标环境具备支持其版本的jvm，否则抛unsupportedclassversionerror。
JVM 是 Java 跨平台能力的唯一执行载体，没有它，.class 文件就是一堆无法运行的二进制废料。
为什么 java HelloWorld 能在 Windows 和 Linux 上跑出相同结果？
因为字节码不直接交给 CPU，而是由各自平台的 JVM 实现来“翻译”——Windows 上是 jvm.dll，Linux 上是 libjvm.so，macOS 上是 libjvm.dylib。它们都严格遵循同一份 JVM 规范，所以对同一段 getstatic、ldc、invokevirtual 字节码指令，做出的行为完全一致。
- 你不需要、也不应该手动调用这些动态库；
java命令背后自动加载对应平台的 JVM 实现 - 不同厂商的 JVM（如 HotSpot、OpenJDK、Corretto）只要兼容规范，就能互换运行同一份
.class - 常见错误：
UnsupportedClassVersionError不是跨平台失败，而是编译用的 JDK 版本高于运行用的 JRE 版本——字节码版本不匹配，和操作系统无关
javac 编出来的 .class 真的“到处能用”吗？
是的，但有个硬前提：目标平台必须装有支持该字节码版本的 JVM。比如用 JDK 21 编译的类，默认生成 class 文件版本 65，若在只装了 JRE 8 的机器上运行，会直接报错 java.lang.UnsupportedClassVersionError: Unsupported major.minor version 65.0。
- 验证方式：
javap -verbose HelloWorld.class | grep "major version" - 降级兼容办法：加
-source 8 -target 8参数（注意：不能用 JDK 21 的新语法，否则编译失败） - 别迷信“一次编译”，实际项目中要明确最低运行环境，并在 CI 中用对应 JRE 测试
JVM 内存结构怎么影响你写的代码？
不是所有对象都存在堆里，也不是所有变量都在栈上——理解运行时数据区，才能避开 OutOfMemoryError 和诡异的 NullPointerException。
-
String str = "hello"中的"hello"存在方法区（Java 8+ 是元空间），而new String("hello")的对象实例才在堆中 - 局部变量（包括引用）存在虚拟机栈里，生命周期绑定方法调用；一旦方法返回，栈帧弹出，引用消失——哪怕堆里对象还活着，也可能被 GC 回收
- 静态变量属于类，存在方法区；但如果你在类初始化时启动线程并持有了该静态引用，就可能造成内存泄漏——GC 不会回收被活跃线程引用的对象
真正容易被忽略的是：JVM 规范不规定 GC 算法细节，所以不同版本、不同厂商的 JVM 对同一段代码的内存行为可能不同。比如 G1 在 JDK 9+ 默认启用，而 Serial GC 在嵌入式场景仍常见——光看代码逻辑不够，得结合部署环境的 JVM 参数一起看。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
