JVM是唯一能直接执行.class字节码的运行时环境，负责内存管理、JIT编译与GC，但不参与.java到.class的编译；其行为随JDK版本演进而变化，核心参数不可动态修改。
JVM不是Java编译器，也不负责把.java源文件变成.class——那是javac干的事
Java字节码到底在哪儿运行？
JVM是唯一能直接执行.class文件的运行时环境。它不认.java，只认javac输出的字节码（ClassFile结构），所有Java、Kotlin、Groovy等JVM语言最终都得喂给它来执行。
- 同一份
.class文件，在Windows上的HotSpot JVM和Linux上的OpenJ9 JVM都能跑，但底层指令翻译完全不同 - 你写的
System.out.println("hi")会被编译成getstatic+ldc+invokevirtual等字节码指令，JVM负责逐条解释或即时编译（JIT）成机器码 - 没有JVM，
java -jar app.jar会直接报错：Error: Could not find or load main class——注意，这不是类路径问题，而是根本没启动JVM进程
内存管理真由JVM全权负责？
是的，但“负责”不等于“全自动”。JVM划出堆（Heap）、方法区（Metaspace）、虚拟机栈、本地方法栈、程序计数器这五块运行时数据区，其中只有堆和方法区是线程共享的，其余均为线程私有。
当用户要求为 Java 代码添加注释、修改注释、审查注释、整理注释格式，或要求按照代码注释规范处理 Java 文件时，使用本技能。本技能用于统一生成和维护 Java 类注释模板、按 Git 对比 release 判断版本号、补充每行代码上方中文块注释、调整注释空行规则，并保持 Java 文件 UTF-8 无 BOM 编码。典型触发场景包括：补充类注释、更新 @version、检查 @author 来源、整理行尾注释、把注释放到代码上一行、检查注释是否符合规范、构建前检查 Java 注释风格。
- 你调用
new Object()，对象一定分配在堆上；但若逃逸分析通过，JIT可能把它栈上分配（Stack Allocation），这完全透明，你无法用代码控制 -
OutOfMemoryError: Java heap space说明堆满且GC后仍无法腾出空间；而OutOfMemoryError: Metaspace往往是因为动态生成大量类（如反复使用ASM或CGLIB代理） -
-Xms和-Xmx只约束堆初始与最大大小，不影响栈大小——栈溢出（StackOverflowError）由-Xss控制，且每个线程独立
为什么不同JDK版本的JVM行为会突变？
因为JVM实现本身在演进，尤其GC算法和JIT策略。比如从JDK 8升级到JDK 17，G1 GC默认开启并发标记，且String去重（-XX:+UseStringDeduplication）不再默认启用；ZGC在JDK 15才转为生产就绪。
立即学习“Java免费学习笔记（深入）”；
-
java -version输出里的JVM字段（如OpenJDK 64-Bit Server VM）才是真正的JVM，java命令只是个启动器 - JDK 11起移除了
javah，JNI头文件改由jextract生成；JDK 17彻底废弃SecurityManager，相关JVM安全检查逻辑已剥离 - 用
jstat -gc <pid></pid>看到的GC统计，底层依赖JVM提供的HotSpotDiagnosticMXBean，换一个非HotSpot的JVM（如GraalVM CE），这个命令可能压根不支持
真正容易被忽略的是：JVM进程一旦启动，其核心参数（如-XX:+UseG1GC、-XX:MaxMetaspaceSize）就不可动态修改；热替换类（HotSwap）仅支持方法体变更，不能增删字段或改变签名——这些限制不是Java语言定的，是JVM规范硬性规定的。
