java跨平台依赖“源码→字节码→jvm→本地机器码”执行模型：javac将.java编译为与平台无关的.class字节码，各平台专属jvm负责将其解释或jit编译为对应机器码，实现“一次编译、处处运行”。
Java 能跨平台，靠的不是语言本身，而是它背后统一的执行模型：源码 → 字节码 → JVM → 本地机器码。核心不在“写一次”，而在“编译一次、由各平台 JVM 各自执行一次”。JVM 是那个把统一字节码翻译成 Windows、Linux 或 macOS 能听懂的指令的“方言翻译官”。
字节码：统一的中间语言
Java 源文件（.java）经 javac 编译器 处理后，不生成 .exe、ELF 或 Mach-O 这类操作系统专属的二进制，而是生成标准的 .class 文件——里面是 JVM 定义的字节码（bytecode）。这种字节码与 CPU 架构无关、与操作系统无关，只认 JVM 规范。只要符合 Java 虚拟机规范（JVMS），任何平台上的 JVM 都能识别同一份 .class 文件。
- 例如：
System.out.println("Hello");编译后，在所有平台上都变成相同的几条字节码指令（如getstatic、ldc、invokevirtual） - 字节码不是机器码，不能被 CPU 直接执行，它是专为 JVM 设计的“伪汇编”
- 不同 JDK 版本生成的字节码可能有版本号差异（如 class 文件魔数 + 主次版本号），但同版本下，Windows 编译的 .class 可直接在 Linux 的同版本 JVM 上运行
JVM：平台定制的执行引擎
JVM 不是单一程序，而是一套针对不同操作系统和硬件架构实现的软件层。Oracle、OpenJDK、Azul 等厂商分别提供 Windows x64、Linux aarch64、macOS ARM64 等多个版本的 JVM。它们共享同一套字节码语义，但底层实现完全不同：
- 内存管理模块调用 Windows VirtualAlloc / Linux mmap / macOS vm_allocate
- 线程调度对接 OS 原生线程（pthread、WinThread）
- JNI（Java Native Interface）桥接 Java 方法与平台特定的 C/C++ 库
- 即时编译器（JIT，如 HotSpot 的 C1/C2）将热点字节码动态编译为对应平台的高效机器码
执行流程：从启动到运行
当你执行 java MyApp 时，实际发生的是：
- JVM 进程启动，加载
MyApp.class及依赖类（通过类加载器子系统） - 字节码验证器检查格式与安全性（防止非法跳转、类型篡改等）
- 解释器逐行读取字节码并模拟执行（冷启动阶段）
- 运行中识别高频方法，触发 JIT 编译，生成该平台原生机器码并缓存
- 后续调用直接跳转至已编译的机器码，获得接近 C 的性能
跨平台的边界与注意事项
跨平台能力强大，但并非无条件：
-
路径分隔符：硬编码
"\"或"/"会出错，应使用File.separator或Paths.get() -
文件编码：默认字符集因系统而异（Windows 通常是 GBK，Linux/macOS 默认 UTF-8），建议显式指定
StandardCharsets.UTF_8 - 本地库依赖：若用了 JNI 调用 .dll/.so/.dylib，这些二进制无法跨平台，需为各平台单独编译并适配加载逻辑
- JVM 版本兼容性：高版本 JVM 可运行低版本字节码，但反之不行；建议开发与生产环境 JVM 主版本一致
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
