如果让我选一个编程新手最容易被绕晕的知识点，Java 的编译运行机制一定排前三。明明学 C 的时候编译完就能跑，到了 Java 这里多出一个“虚拟机”，又多出 JDK、JRE 这些缩写单词，再配上环境变量配置，第一天还没写代码就卡在门口了。这篇东西我就用这些年带新人、自己踩坑的经验，把 Java 从源码到运行、从跨平台原理到 JDK/JRE/JVM 架构这件事彻底讲清楚。不管你是零基础准备入行，还是面试前想把基础概念理顺，看完这几个章节，心里那条线应该能串起来了。
1. Java 到底是什么：一个语言，更是一整套生态
1.1 Java 的出身与它解决的痛点
Java 是 Sun 公司（后来被 Oracle 收购）在 1995 年发布的编程语言，设计口号叫“一次编写，到处运行”（Write Once, Run Anywhere）。这个口号在当年是很有杀伤力的。那时 C/C++ 是主流，但你用 C 写的程序在 Windows 上编译好的 exe，拿到 Linux 上就直接罢工，必须找到源码重新编译一遍，而不同平台的编译参数、依赖库环境千差万别，跨平台是一件非常痛苦的事情。Java 想了一个取巧但极其有效的方案：不直接和操作系统打交道，而是跑在一个叫 JVM（Java Virtual Machine，Java虚拟机）的中间层上。只要某个平台装好了对应版本的 JVM，同一份 Java 程序就能跑起来。
这里要先说清楚一个多数新手会混淆的点：Java 的跨平台不是说“同一个 exe 到处都能双击运行”，而是“同一份字节码可以在任何装了 JVM 的平台上运行”。字节码是 Java 源码编译后的产物，它不是某个 CPU 能直接执行的机器码，而是一套给 JVM 看的指令。这个设计把“应用软件”和“操作系统/硬件”彻底解耦了，代价是你必须额外装一个运行时环境。这个取舍在后面讲 JDK/JRE/JVM 时会反复出现。
1.2 Java 能做什么，适合谁学
到现在，Java 的应用范围还是很广的。企业级后端开发（Spring Boot 那一套）、Android 应用开发（Android 的 App 层用 Java/Kotlin）、大数据生态（Hadoop、Flink、Spark 大量使用 Java/Scala）、金融交易系统、电商平台……这些领域 Java 都是主角。你要说它是不是最“潮”的语言，肯定不是，但它的岗位存量、生态成熟度、长期稳定性在所有编程语言里都属于第一梯队。
所以这篇文章适合这些人看：完全零基础、准备从 Java 入门编程的新手；大学里正在学 Java 基础课的学生；准备 Java 面试但发现 JDK、JRE、JVM、跨平台这些概念答不利索的求职者；以及从其他语言（比如 Python、C）转过来，想快速理解 Java 运行机制的人。基础概念这块，理解了它，后面学 JVM 调优、学 Spring 启动原理的时候，你会省掉大量重新补课的时间。
2. 编译运行全流程：从 .java 文件到程序跑起来的完整链路
2.1 .java、.class 和 JVM：三层结构先立起来
如果你打开一个 Java 项目，会看到大量的 .java 文件，这是人能读写的源码。源码是不能直接运行的，你得先用编译器把它变成 .class 文件，这种文件里装的是一堆“字节码”（bytecode）。字节码是给 JVM 执行的指令，和具体的 CPU、操作系统没有关系。JVM 拿到 .class 文件后，会把它加载进来、校验、然后执行（或者说翻译成当前平台的机器码去执行）。
用生活化的方式理解：.java 文件像一份中文菜谱，.class 文件是翻译好的“国际通用烹饪符号”，JVM 是每个国家都配的“本地厨师”。菜谱用符号写成，全世界的厨师都能看懂，但每个厨师做出来的菜要符合本地口味（也就是适配本地操作系统）。你作为食客（用户）不用关心厨师怎么操作，你只管点菜就行。
这条链路里有一个很多人忽略的点：为什么 Java 非要中间加一层 .class 和 JVM，而不是像 C 那样直接编译成 exe？答案是为了“延迟决定”。C 程序在编译时就把平台相关的信息定死了；Java 把跨平台的决定权从编译期延后到了运行期——编译时只生成平台无关的字节码，运行时才由 JVM 去适配具体平台。这个“延后”的思想在计算机领域到处都是，比如数据库的 SQL 语句、前端的 JavaScript 引擎，内核逻辑都是类似的。
2.2 javac 和 java 两条命令：编译期和运行期的分工
实操层面，你会用到两个最基础的命令：javac 和 java。注意它们的名字，一个是 c（compiler，编译器），一个是直接叫 java（就是启动 JVM 运行程序）。
编译期：javac HelloWorld.java，这条命令把源码编译成 HelloWorld.class。编译期做的事情包括词法分析、语法分析、语义分析、生成字节码。如果源码有语法错误，这一步就会报错，.class 文件不会生成。
运行期：java HelloWorld，这条命令启动一个 JVM，找到编译好的 HelloWorld.class，加载并执行里面的 main 方法。注意，java 命令后面跟的是类名，不是文件名。类名不需要带 .class 后缀，更不能带 .java 后缀，这个细节不少人第一次会搞错。比如你文件叫 HelloWorld.java，里面公开类的名字也叫 HelloWorld，运行的时候写 java HelloWorld，而不是 java HelloWorld.class。
对比一下 Python 和 C，这个链路会更清晰。Python 是纯解释执行（没有显式编译这一步），源码直接交给解释器跑，方便但性能上限低；C 是纯编译执行，编译一次生成机器码，性能高但换平台要重新编译；Java 是“编译一次，到处解释/编译执行”，字节码是中间产物，JVM 用解释器一行行翻译，或者用 JIT（及时编译器）把高频代码段直接编译成本地机器码，这样兼顾了跨平台和性能。
2.3 静态链接还是动态链接：顺带解决一个困惑
最近有个搜索热词叫“java是静态链接的”，这个说法其实是把概念搞混了。Java 默认情况下，类不是一次性全部加载进内存的，而是在用到某个类时才去加载，这个叫“动态加载”或“延迟加载”。JVM 的类加载机制分为加载、验证、准备、解析、初始化五个阶段，其中“解析”阶段做的事是把类的符号引用（比如你代码里写了 System.out，这里的 System 就是个符号）替换成直接引用（真正指向内存里那块地址），这个过程可以发生在类加载时，也可以延迟到第一次使用某个符号时，所以 Java 本质上是动态链接的。
那为什么会有“Java 是静态链接的”这种说法？因为当年 JDK 里确实有个工具叫 rt.jar，编译和运行都要引用它，看起来像静态依赖一大堆。但从 JVM 运行机制来看，Java 跟“把所有依赖都打进一个可执行文件”的静态链接完全是两码事。这个点如果面试被问到，你可以把“类加载机制 + 符号引用替换”这条回答出来，基本就过关了。
2.4 亲手跑一个 HelloWorld：命令行全流程演示
我仍然建议初学者至少用命令行（Terminal/CMD）完整跑通一次 HelloWorld，不要一上来就用 IDE（集成开发环境）一键运行。用 IDE 太方便了，方便到你根本不知道发生了什么，后面遇到“找不到主类”“ClassNotFound”这类报错会一头雾水。
第一步，创建一个文本文件，命名为 HelloWorld.java，内容如下：
public class HelloWorld { public static void main(String[] args) { System.out.println("Hello, Java!"); } }第二步，打开命令行，cd 到该文件所在目录，执行编译：
javac HelloWorld.java此时目录下会多出 HelloWorld.class。你可以用 ls（Mac/Linux）或 dir（Windows）确认。
第三步，执行运行命令：
java HelloWorld控制台输出 Hello, Java! 就算彻底跑通了。
注意：文件编码建议用 UTF-8。Windows 默认编码是 GBK（部分地区老系统），如果你的源码里有中文注释，编译会报编码错误，这个在后面的常见问题部分单独说。
3. 跨平台原理：一次编写到处运行的真相
3.1 为什么 C/C++ 做不到同样的跨平台
先看反面教材。C 语言源码经过编译器变成目标文件，再链接成可执行文件，这个过程生成的机器码是给特定 CPU 架构用的。你在 Windows 上编译出来的 exe，用的是 Windows 的可执行格式（PE 格式）+ Windows API；同一个源码到 Linux 上编译，出来的是 ELF 格式，依赖的是 Linux 系统调用。且不说格式不同，就说系统 API 都不一样，底层肯定没法通用。所以 C 的跨平台策略是“一处源码，到处编译”，你得在每个目标平台上重新编译一次，而且得处理各种平台差异的宏定义。
Java 的策略完全不同：源码编译一次，产出平台无关的字节码，然后每个平台上的 JVM 负责把字节码变成当前平台能跑的机器码。真正在搬运程序的不是你的程序文件，而是 JVM。所以你只需要给每个平台下载对应的 JVM 安装包，你的程序文件从来只有一份。
3.2 JVM 是跨平台的翻译官，但它本身不跨平台
这句话特别重要：Java 语言跨平台，但 JVM 本身不跨平台。Windows 上的 JVM 是微软/ Oracle 针对 Windows 写的，Linux 上的 JVM 是专门为 Linux 写的，它们内部调用了各自平台的系统 API 来分配内存、创建线程、读写文件。你在 Windows 下安装的 JDK 文件夹，不能直接拷到 Linux 上使用，必须在 Linux 上重新安装对应版本的 JDK。
用类比来说，字节码是“世界语”，JVM 是“翻译官”，每个国家需要配一个懂本地语言的翻译官。翻译官本人是本地人，但他能把外语准确翻译成当地话。没有翻译官，世界语再通用也传不出去。
3.3 解释执行与 JIT：JVM 怎么把字节码变成本地机器码
JVM 拿到字节码后，有两种执行方式。第一种是解释执行，一条指令一条指令地翻译成本地操作并执行，简单直接，但速度上不去。第二种是 JIT（Just-In-Time，即时编译），JVM 在运行时会统计哪些代码被频繁执行（热点代码），比如一个外层循环体执行了几百万次，JIT 会把这段字节码直接编译成本地机器码并缓存起来，之后执行这个热点代码就不再逐条翻译了，性能大幅提升。这就是为什么“Java 慢”已经变成了早年间的印象，现代 JVM 的性能通过 JIT、逃逸分析、分层编译等优化，在很长一段场景下并不比 C++ 差太多。
所以“Java 程序在 JVM 上靠着解释器一行行翻译所以很慢”是一个过时认知。现在的 HotSpot VM（Oracle JDK 默认的 JVM）是解释器和 JIT 编译器并存的，先解释执行收集运行数据，再针对热点编译优化。这也是面试常问的“Java 是编译型还是解释型语言”的底层答案：它既不是纯编译型，也不是纯解释型，而是“编译生成字节码 + 运行时混合执行”的形态。
3.4 跨平台的价值边界：一次编写并不等于处处零配置
说清楚原理之后，要泼一盆冷水：跨平台不是“银弹”，实际项目里还是有一些坑。比如文件路径分隔符，Windows 是反斜杠 \，Linux 是正斜杠 /，你写死感叹号路径在 Windows 上跑没问题，部署到 Linux 服务器上路径就炸了，所以正规开发要用 File.separator 或 Paths.get() 去拼接；再比如环境变量大小写敏感问题、系统默认字符集问题、文件权限问题，这些都需要代码层面额外处理。跨平台框架（JVM、Spring Boot）解决的是“语言和运行时层面的差异”，不解决“你的代码里写死了 Windows 独有路径”的毛病。
绝大多数时候，Java 团队的工作流是：开发者在 Windows 或 Mac 上编码，用 Maven/Gradle 构建出 jar 包或 war 包，然后上传到 Linux 服务器运行。这个 jar 包不需要在 Linux 上重新编译，因为里面是已经生成好的字节码，Linux 的 JVM 直接加载运行。这就是工作中最常体验到的“一次编写到处运行”。
4. JDK/JRE/JVM 架构拆解：三者到底是什么关系
4.1 包含关系：JDK 里装着 JRE，JRE 里装着 JVM
正式学习之前，你需要记住一个包含关系公式：
JDK（Java Development Kit，Java开发工具包） > JRE（Java Runtime Environment，Java运行环境） > JVM（Java Virtual Machine，Java虚拟机）。
JDK 是给开发者用的，里面包含了完整的 JRE，还包含了各种开发工具：javac（编译器）、java（启动器）、jar（打包工具）、javadoc（文档生成工具）、jdb（调试器）、jps（查看 Java 进程）、jstack（查看线程快照）等等。所以你装一个 JDK，既能编译，又能运行。
JRE 是给普通用户用的，里面包含 JVM 和 Java 核心类库，但不包含 javac。换句话说，如果你的电脑只需要运行别人打包好的 Java 程序（比如某个桌面工具、某个 jar 包），装 JRE 就够了；你想自己写代码编译，必须装 JDK。
JVM 是 JRE 最核心的部分，也是程序真正运行的地方，负责字节码的执行、内存管理、线程调度、垃圾回收等等。这三个很容易记：Kit 是工具包，Runtime 是运行环境，Machine 是底层的虚拟机。
这里有个发展变化值得一提：从 JDK 9 开始，Oracle 不再单独发布 JRE 的独立安装包，而是要求开发者直接装 JDK。你可能会说“那我跑程序还非得装 JDK 吗？”其实 JDK 里的 jlink 工具可以定制一个只包含必要模块的最小运行时镜像，用来替代老式的 JRE。这个变化主要是为了让 Java 运行时更轻量、模块化，但对于初学者，记住一个结论就行：直接下载安装 JDK，所有问题都解决了。
4.2 打开 JDK 目录，看看里面到底有什么
如果你现在打开 JDK 的安装目录，典型结构是这样的：
- bin/：包含所有可执行命令，javac.exe、java.exe、jar.exe 都在这里
- lib/：存放 Java 类库的打包文件，以及一些工具依赖的库
- include/：包含一些 C/C++ 头文件，用于 JNI（Java Native Interface，Java本地接口）开发，需要调用 C/C++ 本地方法时才会用到
- jmods/：模块化 JDK 的模块文件（JDK 9 以后才有）
- conf/：存放 JVM 和工具运行时的配置文件，比如安全策略文件
你要重点关注的是 bin 目录。为什么配置环境变量时要指向这个目录？因为你希望在任何目录下都能直接执行 javac 和 java，而不需要输入一长串绝对路径。操作系统查找命令的逻辑是去 PATH 环境变量列出来的目录里逐个找，你把 JDK 的 bin 目录加进 PATH，系统才能在全球任意目录识别 java 命令。
4.3 JVM 运行时数据区：程序在虚拟机里是怎么存放数据的
JVM 在执行 Java 程序时，会把内存划分成几个区域，这叫运行时数据区（Runtime Data Areas）。面试里最常问的就是这一块，但很多新手一开始就把它背混了，我尽量用直白的方式讲。
- 程序计数器（Program Counter Register）：记录当前线程正在执行的字节码行号。线程切换时，程序计数器让每个线程能回到之前执行的位置。它是 JVM 规范里唯一没有内存溢出问题的区域。
- 虚拟机栈（JVM Stack）：线程私有，每个线程一个栈。每个方法调用时会压入一个栈帧（Stack Frame），栈帧里存放局部变量表、操作数栈、方法返回地址等信息。方法调用结束，栈帧就弹出。如果递归太深没有出口，这里会报 StackOverflowError（栈溢出）。
- 本地方法栈（Native Method Stack）：线程私有，专门服务本地方法（用 C/C++ 写的、通过 JNI 调用的方法）。
- 堆（Heap）：线程共享，绝大多数对象实例都分配在这里，也是垃圾回收（GC）主要管理的区域。堆内存不足会报 OutOfMemoryError。
- 方法区（Method Area）：线程共享，存放类信息、常量、静态变量等。在 HotSpot VM 里，JDK 8 以前叫“永久代”，JDK 8 开始改为“元空间”（Metaspace），并且不再使用 JVM 堆内存，而是使用本地内存。
理解这块有个生活化类比：栈像方法调用的“任务清单”，一层套一层，执行完就划掉；堆像仓库，所有的数据物品都存在里面，GC 就是定期清理仓库里没人要的旧货；方法区像“公司规章制度手册”，每个类的方法定义都记录在里面。
新手不必死记硬背所有细节，但要知道：new 出来的对象在堆里，局部变量在栈里，类信息在方法区/元空间里。这个认知能帮你后面看懂内存泄漏和 OOM（内存溢出）问题。
4.4 执行引擎与垃圾回收：JVM 运行时的两大关键机制
JVM 的核心执行引擎负责真正“干活”：解释字节码、执行 JIT 编译优化、做垃圾回收。前面已经解释了 JIT，这里重点说说垃圾回收（Garbage Collection，GC）。
Java 和 C/C++ 一个显著区别是，Java 不让你手动释放内存（没有 free 和 delete 这种关键字），而是由 JVM 的 GC 自动回收不再使用的对象。GC 的大致逻辑是：从一组称为“GC Roots”的根对象出发，沿着引用链条扫描，凡是无法从根对象到达的对象，就认定为“垃圾”，可以被回收。这就是“可达性分析”。
GC 的算法有很多代际划分：新生代（Young Generation）用复制算法，老年代（Old Generation）用标记-清除或标记-整理算法；收集器越来越智能，从 Serial、Parallel 到 CMS，再到如今主流的 G1、ZGC。初学者不需要把每个收集器的参数都背下来，但应该理解：Java 程序的内存不是无限大的，对象也不是一直存活的，GC 调优是 JVM 领域一项进阶技能。
这里产生一个新的常见疑问：既然有 GC，为什么还会内存溢出？答案是 GC 只能回收“不可达”的对象。如果你的代码有意无意地持有了大量对象的引用（比如静态集合不断往里塞数据），这些对象一直是“可达”的，GC 就不会动它们，堆内存最终被填满，就报 OutOfMemoryError。GC 的边界和代码的质量永远是配合关系，不是替代关系。
5. 环境变量配置实操：JAVA_HOME、PATH、CLASSPATH 到底在干嘛
5.1 下载安装与版本选择：8、11、17、21 怎么选
网上关于“Java 版本”的讨论非常多，你可能会看到“JDK 8 是神”“JDK 17 才是 LTS（长期支持版本）”之类的说法。对一个刚入门的人，我的建议是：如果是为了学习基础和应付考试面试，选 JDK 8 或者 JDK 17 都行；如果是准备做新项目、跑主流框架，直接选 JDK 17 或 JDK 21（这两个都是 LTS，社区支持完善）。
为什么不说“越新越好”？因为 JDK 8 是历史上使用最广泛的版本，大量老项目的技术栈还是基于 8 的，而且企业面试题最爱问“JDK 8 的 HashMap 为什么有红黑树”这类问题。但 JDK 8 毕竟是 2014 年的产品，Switch 表达式、var、密封类、虚拟线程这些新特性都没有，长期学旧版本会让你对外面的技术发展一无所知。实用主义的选择是：学习时用 17，看懂老代码时知道 8 的语法差异即可。
JDK 的下载渠道就认准 Oracle 官方或者 OpenJDK 发行版（比如 Adoptium 社区版，国内也有镜像源）。下载时注意操作系统和 CPU 架构选对，Windows 选 x64 或 x64 MSI 安装包，macOS 目前主流是 Apple Silicon（arm64）和 Intel（x64）两种，要看清楚。
5.2 JAVA_HOME 和 PATH 的配置逻辑
假设你已经装好了 JDK，接下来要配置三个环境变量。
第一个是 JAVA_HOME。它的值是 JDK 安装的根目录，比如 C:\Program Files\Java\jdk-17。为什么要有这个变量？因为很多第三方工具（Tomcat、Maven、Gradle、IDEA）不需要自己去猜你的 JDK 装在哪，它们约定好读 JAVA_HOME 变量就能找到。你以后升级 JDK 时，只需要改 JAVA_HOME 一个变量，其他所有依赖它的工具自动跟着切换。它相当于一个“统一入口”或“电话簿”。
第二个是 PATH。前面说过，系统执行命令时按照 PATH 里列出的目录顺序去查找，你需要把 JDK 的 bin 目录加进去，比如 %JAVA_HOME%\bin（Windows 写法）或 $JAVA_HOME/bin（Linux/macOS 写法）。这样做的效果是：在任何目录下敲 java、javac 都能被系统找到。如果不配 PATH，你每次得输入完整路径，比如 C:\Program Files\Java\jdk-17\bin\java，这不是人能坚持干的事。
第三个是 CLASSPATH。这是一个历史遗留变量，早期 JDK 版本里，JVM 需要靠它来定位 .class 文件和第三方 jar 包的位置。但从 JDK 1.5 起，编译器（javac）已经能根据 import 和 classpath 参数的配置自动搜索类，而且 IDE 和 Maven 都是自己管理依赖，不会依赖系统 CLASSPATH。所以现在安装 JDK 时，实战中基本不需要手动配置 CLASSPATH。如果你在网上看到老教程让你配 CLASSPATH，配置成 .（表示当前目录），不配也不影响现代开发。面试时把它的起源和用途说清楚，明白它现在如何被取代就够了。
5.3 配置验证：java -version 与 javac -version
配置完成后，重新打开命令行（重新打开是为了让系统重新读取环境变量），执行：
java -version javac -version如果两个命令都能正常输出版本号，说明 JDK 安装和 PATH 配置成功。注意一个细节：java -version输出的是 JVM 的运行版本，javac -version输出的是编译器的版本。正常情况下两者一致。
有一个非常隐蔽的问题：如果你的电脑里装了不止一个 JDK，或者有些软件（比如 IDEA 自带 JBR）提前改过 PATH，可能出现java -version是一个版本、javac -version是另一个版本的情况。这是因为 PATH 里同时存在多个 JDK 目录，系统按顺序先找到了老的 java，后找到了新的 javac。解决办法是检查 PATH 列表里所有 Java 相关路径，只保留一个，把 JAVA_HOME 指向你真正想用的版本，并把 %JAVA_HOME%\bin 放在 PATH 靠前的位置。
Windows 环境变量 GUI 的多行堆叠容易看花眼，我建议用命令行检查实际生效的列表：
where java会列出所有 java.exe 的位置顺序，你能直观地看到谁排在前面。
macOS 上有时会显示一个系统自带的 Java 路径（比如 /usr/bin/java 指向的是 /Library/Internet Plug-Ins 之类的旧版本），这通常是苹果预装兼容层，你安装并配置好 JDK 后，调整 JAVA_HOME 即可。具体方法是用/usr/libexec/java_home -V查看所有已安装版本的路径，然后在 shell 配置文件中 export 对应的 JAVA_HOME。
6. 常见报错与排查技巧：从命令行一点一点捋
6.1 'javac' 不是内部或外部命令
新手第一个常见报错是，输入 javac 之后系统提示“不是内部或外部命令”（Windows）或“command not found”（macOS/Linux）。原因很简单：javac 这个可执行文件所在的 bin 目录没有被加进 PATH。排查步骤也很固定：先确认 JDK 是否真的装好了——打开 JDK 安装目录看里面有没有 bin 文件夹，文件里有没有 javac.exe；再确认环境变量里的 PATH 是否包含了这个 bin 目录；如果配置没问题，重新打开命令行再试一次。
这里要注意，修改环境变量后，已经打开的命令行窗口不会自动刷新环境变量，必须关掉重开。我见过有人配置完 JAVA_HOME 后在旧窗口里敲了半天 java，一直报错，最后发现只是没开新窗口，白折腾半小时。
6.2 找不到或无法加载主类
运行java HelloWorld时报错 Error: Could not find or load main class HelloWorld。常见原因有三类：
第一，类名写错了。Java 是大小写敏感的，HelloWorld 和 helloworld 是两个完全不同的类名。
第二，运行命令时不在 .class 文件所在的目录。如果 .class 文件在子目录里，你得 cd 过去，或者用 classpath 参数指定：java -cp . HelloWorld。-cp就是 classpath 的缩写，.表示当前目录。
第三，编译后的包路径和你运行的类名不匹配。如果你的源码第一行写了package com.demo;，那 .class 文件必须在 com/demo 这个目录结构下，运行命令也要带完整包名：java com.demo.HelloWorld。
对“找不到或无法加载主类”最有用的排查命令是先看看目录下到底有没有 .class 文件。如果你编译时源码有错误，javac 会中止，不会生成 .class，这时你直接去运行，自然找不到主类。所以这类问题的排查顺序是：看源码语法对不对 -> 看编译有没有成功 -> 看目录位置 -> 看类名大小写。
6.3 编码问题：编译报错“编码 GBK 的不可映射字符”
在 Windows 默认 GBK 编码环境下写了一个包含中文注释的 Java 文件，然后用javac HelloWorld.java编译，可能会报“编码 GBK 的不可映射字符”。原因是 javac 默认按系统平台的编码去读取源码文件，如果你的文件实际保存为 UTF-8（现在主流文本编辑器的默认编码），javac 却用 GBK 去解码，中文字符就会变成乱码报错。
解决办法有两种。第一种，编译时显式指定编码：
javac -encoding UTF-8 HelloWorld.java第二种，在文本编辑器里把文件编码统一改成 UTF-8（无 BOM 格式），并在 IDE 里也设置项目编码为 UTF-8。我建议在团队开发中强制统一 UTF-8，因为 Linux 服务器上默认编码就是 UTF-8，Windows 上如果不统一，源码在 Windows 上编译正常、送到 Linux 上编译就报编码错误，非常麻烦。
6.4 ClassNotFoundException 与 NoClassDefFoundError 的区别
这两个典型问题放在一起讲，面试极爱问。ClassNotFoundException 是异常，发生在加载类阶段——你显式地通过 Class.forName() 或运行时的类名加载一个类，但类路径下找不到这个类；NoClassDefFoundError 是错误，发生在类已经编译完成、曾经被加载过，但运行到某个时机又需要该类时发现它不在了（比如类路径被改过、或者类初始化失败导致 JVM 认为该类不可用）。
实际开发中的区别是：ClassNotFoundException 通常是你依赖的 jar 包没引入；NoClassDefFoundError 通常是代码里直接 new 的对象所属类，在编译期存在、运行期缺失，多发生在依赖冲突或漏包部署。遇到这两个报错，重点检查 classpath、jar 包是否完整、Maven/Gradle 依赖是否有冲突。
6.5 多版本 JDK 切换的实操建议
现实情况是，你电脑上很可能同时存在多个 JDK。老项目要求 JDK 8，新项目要求 JDK 17，IDEA 自带的 JBR 又是一套，这个切换如果不处理好，会导致各种诡异报错。
我的经验是：不要频繁去改系统全局的 JAVA_HOME，因为全局变量改来改去很容易引发“密码对了门锁不开”式的连锁错误。更好的方案是：
- 在 IDEA 的 Project Structure 里给每个项目单独设置 JDK 版本（SDK 指定某个 JDK 路径）；
- 在命令行场景下，用版本管理工具。Windows 可以用环境变量快速切换脚本（比如写一个 setjdk8.bat 和 setjdk17.bat），macOS/Linux 可以用 sdkman 或 jenv 这类工具；
- Maven 项目可以在 pom.xml 里锁定 java.version，构建时由 Maven 指定的编译器插件去按版本编译，不受 shell 里 JAVA_HOME 的干扰。
命令行临时切换也可以在当前窗口设置，比如 Windows PowerShell 里：
$env:JAVA_HOME="C:\Program Files\Java\jdk-17" $env:PATH="$env:JAVA_HOME\bin;$env:PATH"当前窗口关闭后恢复原样，不影响系统其他程序。这个技巧很适合不想动全局配置的人。
7. 踩过几次坑之后的学习建议
7.1 学基础阶段，我强烈建议多做三件事
第一件事，亲手在命令行编译运行几个 Java 文件，不要一上来就依赖 IDEA 的绿色三角形按钮。IDEA 一键运行太方便了，方便到让你根本感知不到“编译”这一步的存在，而编译和运行恰恰是 Java 最核心的概念。第二件事，用 jps 命令看看当前有哪些 Java 进程，用 javap -c 反编译一个 .class 文件，亲眼看看字节码长什么样子——它看起来像是另一种“汇编语言”，但每一行都会让你对“源代码和运行代码不是同一层”这件事印象深刻。第三件事，主动去制造一个错误，再把它解决。比如故意把 main 方法签名写错（少了 public static），看看会报什么错；故意把 package 路径写错，看看“找不到主类”长什么样。犯过错之后，你才真正理解规则。
7.2 用 JDK 自带工具做一个小实验
写一个简单的类：
public class Demo { public static void main(String[] args) { int result = add(10, 20); System.out.println(result); } static int add(int a, int b) { return a + b; } }编译后执行：
javac Demo.java javap -c Demo你会看到 add 方法对应的字节码指令，比如iload_0、iload_1、iadd、ireturn这些。明明你写的是 Java，为什么编译出来是这种以 i 开头的指令？因为它们就是 JVM 的“机器码”，专门为 JVM 设计和定义的。看到了吗，跨平台原理在字节码这一层就是活生生的现实：不管你在哪台电脑上编译，只要内容一样，得到的字节码完全一样。
7.3 把这些概念带进后续学习的路径里
理解了编译运行、跨平台和 JDK/JRE/JVM 之后，你的学习路径可以这样推进：先熟练 Java 数据类型、流程控制、面向对象（类、继承、封装、多态）、集合框架，这是基础；再学异常处理、IO、多线程、网络编程，这是进阶；同时尽早接触 JVM 的内存模型和垃圾回收，因为面试和实际调优都需要；紧接着学 MySQL、Spring/Spring Boot，做项目；回过头再深化 JVM 调优、并发编程、设计模式。
为什么我建议回头再深化？因为 JVM 调优如果一开始就学，你是没有体感的——你没经历过内存溢出，就不知道堆和栈调参的意义；你没处理过线程阻塞，就不知道 jstack 是什么用的。先遇到问题，再回来对照 JVM 原理，才记得最牢。
我个人比较深的体会是：Java 入门阶段最大的敌人不是语法，而是“过早依赖工具”。IDE、Maven、框架这些工具把太多复杂性藏起来了，初学者以为自己会了，其实什么都没看到。只要你愿意在命令行里多敲几行命令，多看几眼报错信息，多动手拆一拆 JDK 目录和 .class 文件，Java 的骨架就会在你脑子里立起来。后面再学什么框架都不慌，因为你清楚底层发生了什么。
哈希表全解析)
