Java源文件通过javac编译为.class字节码，经JVM类加载（加载、链接、初始化）、执行引擎（解释器/JIT）运行，main方法启动后JVM存活至非守护线程结束。
Java源文件怎么变成.class字节码
你写的 .java 文件不会直接被CPU执行，必须先经过编译器处理。JDK自带的 javac 命令负责这一步：它读取源码，检查语法、类型、符号引用等，生成符合JVM规范的二进制 .class 文件。
注意几个关键点：
-
javac不做任何优化（比如内联、逃逸分析），这些留给JVM运行时做 - 一个
.java文件里可以定义多个类，但只能有一个public类，且文件名必须和它一致 - 编译后的
.class里没有注释、无用空格，但保留了部分调试信息（如行号、局部变量表），可通过-g:none关闭 - 泛型在编译期被擦除，
List和List编译后都是List
JVM加载.class文件的三个核心阶段
类加载不是简单地把字节码读进内存，而是分阶段完成的：加载（Loading）、链接（Linking）、初始化（Initialization）。其中链接又细分为验证（Verification）、准备（Preparation）、解析（Resolution）。
常见误区是认为“new对象时才加载类”——其实不一定。例如静态字段访问、反射调用、子类初始化都会触发父类加载；而单纯声明一个类引用（如 MyClass obj;）不会触发加载。
立即学习“Java免费学习笔记（深入）”；
典型问题场景：
- 类路径错误导致
ClassNotFoundException：检查-cp或CLASSPATH是否包含目标.class所在目录或jar - 版本不兼容报
UnsupportedClassVersionError：说明用高版本JDK编译、低版本JVM运行，需统一JDK/JRE版本 - 双亲委派被破坏（如自定义类加载器未正确委托）可能引发
NoClassDefFoundError而非ClassNotFoundException
字节码如何被真正执行：解释器 vs JIT编译器
JVM不直接执行字节码，而是通过执行引擎处理。早期JVM纯靠解释器逐行翻译字节码为机器码，慢；现代HotSpot JVM默认启用JIT（Just-In-Time）编译器，在运行时识别热点代码（如反复执行的方法），将其编译成本地机器码并缓存。
这个过程对开发者透明，但影响真实性能表现：
- 刚启动时响应慢（解释执行为主），运行一阵后变快（JIT生效），这就是“预热”现象
-
-XX:+PrintCompilation可打印哪些方法被JIT编译，-XX:+UnlockDiagnosticVMOptions -XX:+PrintInlining查看内联决策 - 某些场景（如短生命周期应用、CI构建脚本）可关掉JIT：
-Xint强制纯解释模式，避免预热开销 - 方法内联受方法大小、调用次数、是否为虚方法等限制，
final方法更容易被内联
从main方法开始到进程退出发生了什么
你敲下 java MyClass，JVM会启动一个主线程，找到 MyClass.main(String[]) 方法入口，压栈执行。但整个生命周期远不止于此：
- main线程结束 ≠ JVM退出：只要还有非守护线程在运行（如Swing事件线程、未关闭的线程池、Timer任务），JVM就继续存活
- 对象不是“用完就删”，而是由GC决定何时回收；即使显式置为
null，也不代表立即释放内存 -
System.exit()会强制终止所有线程、执行shutdown hooks，然后退出；而正常return只是结束main线程 - 如果main抛出未捕获异常，JVM会打印堆栈并退出，此时
finally块仍会执行，但shutdown hooks不一定来得及跑完
最常被忽略的是资源清理时机：静态初始化块只执行一次，但类卸载（即从方法区移除）极难发生——除非使用自定义类加载器且该加载器本身被回收，否则 .class 数据会长期驻留。
