JDK不是虚拟机，JDK是Java开发工具包的缩写，而JVM是Java虚拟机，两者是包含与被包含的关系JDK里装着JVM，但JDK远不止一个JVM。
很多人刚开始学Java时,下载了JDK，装好之后发现能运行Java程序，就误以为“JDK就是那个跑程序的虚拟机”，这个误区在编程初学者中相当常见，实际拆开来看，JDK和JVM的关系可以用一句话概括：JDK是整套开发工具箱，JVM只是工具箱里负责“执行”的那一个零件。
JDK和JVM的区别是什么，为什么容易混淆
JDK和JVM的混淆,主要源于Windows安装JDK后，系统服务里会出现一个叫“Java Virtual Machine”的进程，加上日常开发中，大家很少手动去启动JVM，更多是直接调用java命令，而java命令背后启动的正是JVM，一来二去，就成了“JDK就是JVM”。
但两者的定位截然不同：
- JVM（Java Virtual Machine）：一个抽象的计算机，负责执行字节码文件，它屏蔽了操作系统和硬件的差异，是Java“一次编译，到处运行”的基石。
- JDK（Java Development Kit）：一个完整的软件开发套件，包含JVM、Java编译器（
javac）、调试器（jdb）、文档生成工具（javadoc）、打包工具（jar）以及大量基础类库。
| 对比项 | JVM | JDK |
|---|---|---|
| 定位 | 运行时环境 | 开发环境 |
| 是否包含编译器 | 否 | 是（javac） |
| 能否单独安装 | 可以（配合JRE） | 可以 |
| 主要使用者 | 运行程序的普通用户 | 编写代码的程序员 |
很多人安装完JDK后,几乎不碰javac，只用IDE（集成开发环境）点“运行”按钮，IDE后台帮你调用了JDK里的编译器和JVM，让你误以为那个“运行”按钮就是JDK的全部，你点一下按钮，IDE至少调用了编译器（javac）把.java源码变成.class字节码，再调用JVM去解释执行字节码，同时还可能调用了文档生成工具来更新API文档。
JDK和JRE与JVM是什么关系，你真的懂吗
搞清楚JDK和JVM后,中间还有一个绕不开的角色JRE（Java Runtime Environment，Java运行时环境）。
这三者的关系在Java圈有个经典比喻：JVM是发动机，JRE是装了发动机的汽车，JDK是汽车制造厂，工厂里不仅有整车（JRE），还有生产工具（编译器、调试器）。
- JVM：只负责执行字节码，本身什么文件都读不了，连最基本的类库都没配齐。
- JRE
：在JVM外面包了一层Java标准类库，比如
java.lang、java.util、java.io这些常用API，以及类加载器和一些基础运行文件，装了JRE，就能正常运行Java程序。 - JDK：在JRE基础上，额外增加了
bin目录下的一堆开发工具，你打开JDK安装目录，bin文件夹里能看到javac.exe、java.exe、javadoc.exe、jar.exe、jdb.exe等几十个可执行文件。
从JDK 9开始，官方调整了发布模式，不再提供独立的JRE安装包，想装JRE，要么下载完整JDK，要么用jlink命令自己裁剪一个精简运行时，这意味着JDK已经事实上的涵盖了JRE的全部内容。
区分三者的记忆锚点：
- JDK = JRE + 开发工具
- JRE = JVM + 核心类库
- JDK的bin目录下有一个
java.exe，它运行时不代表JDK在跑，而是JVM在跑
JVM跨平台到底是什么意思，面试官最爱考的知识点
很多文章说“JVM跨平台”，其实不够严谨，跨平台的不是JVM本身，而是Java程序。各个操作系统上的JVM版本并不相同Windows有Windows版JVM，Linux有Linux版JVM，macOS有macOS版JVM，但不管是什么平台的JVM，它们都能执行同一份.class字节码文件。
JVM充当了翻译官角色
程序员写一段代码,保存为Hello.java，用javac编译后得到Hello.class，这个.class文件是“中性”的字节码，不针对任何特定CPU指令集。
当你把Hello.class放到Windows上，Windows版的JVM逐行翻译成Windows能懂的机器码；放到Linux上，Linux版JVM翻译成Linux能懂的机器码。字节码只有一份，翻译官在不同平台各有一个版本，这就是跨平台的真相。
行业内公认的数据是,Java字节码在主流操作系统上的兼容性优于其他编译型语言，这也解释了大量企业级应用选择Java作为后端语言的原因。
一次编译，到处运行的前提条件
- 目标机器安装了对应平台的JRE（或JDK）
- 源文件和目标机器的字节码版本兼容（比如用JDK 17编译的class文件，不一定能在JDK 8的环境下运行）
如果你的代码里使用了某个JDK版本才有的新特性,比如Java 14的records，那在旧版本JVM上强行运行会直接报UnsupportedClassVersionError，所以部署线上程序时，务必要确认服务器上的JDK版本和编译环境一致或更高。
怎么查看自己电脑上的JDK和JVM版本
实操层面,验证JDK和JVM关系最直观的方法，就是打开命令行输入命令：
java -version：显示JVM版本信息，实际读取的是JRE所在的运行库javac -version：显示Java编译器版本，只有装了JDK才有这个命令
如果输入java -version有输出，但javac -version报“不是内部或外部命令”，说明你机器上只装了JRE，没装JDK，很多编程新手问“jdk和jre的区别是什么”，这个问题一测便知。
在Linux服务器上排查问题,更常用的命令是：
which java：查看java可执行文件路径readlink -f $(which java)：追溯软链接，找到真实的安装目录ls $JAVA_HOME/bin：查看bin目录下是否存在javac，以此判断装的是完整JDK还是精简JRE
在IDE里如何确认真实JDK路径
很多人在IntelliJ IDEA或Eclipse里配置过“Project SDK”或“JRE”，如果配置错误，程序运行时会报“Error: Could not find or load main class”，这时检查路径的方式是：File → Project Structure → SDKs → 确认JDK home path指向的是你解压JDK的根目录，而不是指向bin目录，也不是指向jre子目录。
一个JDK中包含了几个JVM
一个JDK里通常只捆绑一个标准JVM，但当你打开JDK安装目录，会在jre/lib/下找到server和client两个文件夹，里面各有一个jvm.dll，这两个都是JVM的实现，但虚拟机的运行模式不同：
- Server VM：启动慢，但运行期优化更激进，适合长时间运行的服务端程序
- Client VM：启动快，占用内存少，适合桌面应用或短生命周期进程
从JDK 9以后，Oracle官方统一了模式，只保留Server VM，并引入了模块化系统，可以通过jlink定制包含特定模块的轻量级JRE，你用Linux服务器部署Spring Boot应用时，实际跑的就是这种“定制版”JVM环境，而不是完整的全套JDK。
JVM内部在搞什么名堂
弄清JDK和JVM的关系后,再看一眼JVM的内部结构，有助于加深理解，JVM主要包含以下子系统：
- 类加载器（ClassLoader）：负责把
.class字节码装载进内存，Java的“双亲委派机制”就在这里实现 - 运行时数据区（Runtime Data Areas）：包括堆（Heap）、栈（Stack）、方法区（Method Area）、程序计数器（Program Counter Register）、本地方法栈（Native Method Stack）
- 执行引擎（Execution Engine）：负责解释字节码，并做即时编译（JIT）优化
- 垃圾回收器（Garbage Collector）：自动管理堆内存的回收，不用程序员手动释放
当你用java -jar app.jar运行一个Spring Boot应用时，你敲下的这个java命令实际上完成了三件事：启动JVM进程 ➜ 通过类加载器把jar包内的Application.class装入堆内存 ➜ 执行引擎开始解释main方法入口，JDK里的java.exe只是一个启动器，真正干活的都是JVM。
选JDK还是纯JVM
初学者最关心的一个场景是：我只是想跑别人写好的Java程序，要不要装完整JDK？
分情况看：
- 只是想跑一个
jar包，可以只装JRE（JDK早期版本提供），或者用jlink精简一个定制运行时，这样体积更小、攻击面更少 - 需要写代码、编译、调试、打包，必须装JDK
- 在云服务器上部署项目,多数情况下直接装完整JDK，因为需要应付随时可能出现的编译需求或线上排错
云服务商（如简米云、酷番云的镜像市场）默认提供的Java镜像，几乎都预装了完整JDK，原因就是开发者在服务器上经常需要临时打补丁、改代码重新编译，如果只装了JRE，关键时刻会卡在“没有javac”这一步。
回答几个常见追问
JDK安装目录下的“jre”文件夹可以删掉吗
可以删,但没必要，删掉jre文件夹后，依赖Idea等工具自带的JDK运行Java程序没有问题，但如果你手动在命令行使用java命令，可能会提示找不到运行时，完整JDK的体积也就两百多MB，多花这点磁盘空间换省心和兼容，值得。
Oracle JDK和OpenJDK有什么区别
Oracle JDK是Oracle公司发布的商业版本，以前包含一些闭源组件，比如Java Flight Recorder，OpenJDK是开源参考实现，绝大多数逻辑代码与Oracle JDK一致，只是缺少少量商业功能，自JDK 12起，Oracle JDK和OpenJDK的代码基本同源，绝大多数普通项目直接使用OpenJDK完全足够。
JDK版本越高越好吗
不是。高版本JDK能向下兼容旧代码，但旧版本运行时跑不了新编译的代码，企业生产环境普遍停留在JDK 8或JDK 11，因为这两个版本是长期维护（LTS）版本，做新项目，可以考虑JDK 17或JDK 21，尤其是使用Spring Boot 3.x时，强制要求JDK 17以上，在百度搜索“jdk哪个版本好用”，大量行业共识指向LTS版本作为生产首选，原因就是稳定性和安全补丁周期最长。
最后收束一下：JDK和JVM不是同一个东西，JDK像个装备齐全的工具箱，JVM只是其中一把最核心的扳手，你写的是Java源代码，编译出来的是字节码，真正读懂字节码并让计算机执行的东西，是藏在JDK深处的JVM。弄清这一层，后续看类加载机制、内存模型、垃圾回收算法时，就有了地基。