为何OpenJDK中存在两类相似的Hotspot JVM实现？

别慌，这俩根本不是两个JVM实现，是分工完全不同的上下层组件：

• Hotspot目录：实打实的JVM核心
  这部分是用C/C++写的底层虚拟机实现，字节码解释、JIT编译、GC内存回收、线程调度这些最核心的VM功能全在这儿。你觉得它没入口点是因为JDK的启动逻辑在jdk/src/share/bin/java.c这类启动代码里，最后会加载Hotspot的核心库并初始化，它本身是个被调用的库，不是独立可执行程序。

• java.base里的“VM类”：Java层的交互接口
  你看到的那些自称“Java VM”的类，比如java.lang.Runtime、sun.misc.Unsafe（新版本换成jdk.internal.misc.Unsafe），还有java.lang.VirtualMachine，都是Java代码写的上层接口。它们本身不实现VM功能，只是通过JNI调用Hotspot底层的Native代码，给Java程序提供操作VM的入口——比如让你获取内存信息、调用底层指令，不用自己写Native代码。

为啥要这么设计？ #

• 分层解耦：底层VM专注高性能、底层优化，上层Java接口专注易用性，两边分开维护，改底层实现不影响上层Java代码，改上层API也不用动VM核心。
• 规范兼容：Java语言规范定义了一些和VM交互的标准API，java.base里的类是这些规范的落地实现。哪怕以后换个VM（比如OpenJ9），只要遵循规范，上层Java代码照样能跑。
• 历史延续性：JDK6还没模块化，早期就把核心Java类和Hotspot的Native实现分开维护了。JDK9搞模块化后把核心Java类归到java.base，但Hotspot作为核心组件的结构没变，一直延续到现在。

你的理解偏差 #

你把java.base里的Java层接口当成了JVM实现，其实它们只是调用底层VM的“门面”，真正干活的全在Hotspot的C/C++代码里，俩是上下层关系，不是两个独立的JVM。

内容的提问来源于stack exchange，提问作者AGoodSeal