根据Java各个组成部分的功能来进行划分：

JDK（Java Development Kit）：Java程序设计语言、Java虚拟机、Java类库这三部分统称。JDK是用于支持Java程序开发的最小环境。 JRE（Java Runtime Environment）：Java类库API中的Java SE API子集和Java虚拟机这两部分统称。JRE是支持Java程序运行的标准环境。

按照技术所服务的领域来划分，或者按照技术关注的重点业务来划分：

Java Card：支持Java小程序（Applets）运行在小内存设备（如智能卡）上的平台。 Java ME（Micro Edition）：支持Java程序运行在移动终端（手机、PDA）上的平台，对Java API有所精简，并加入了移动终端的针对性支持，这条产品线在JDK6以前被称为J2ME。注意的是，现在智能手机上主要使用的Java语言开发程序的Android并不属于Java ME。Java ME是在以前非智能手机上运行的一些程序，可以在程序启动的时候看到咖啡杯。像塞班系统每次打开应用和游戏时，显示的那个白色底，大大的Java图标就是Java ME。 Java SE（Standard Edition）：支持面向桌面级应用（如window下的应用程序）的Java平台，提供了完整的Java核心API，这条产品线在JDK 6以前被称为J2SE。 Java EE（enterprise Edition）：支持使用多层架构的企业应用（如ERP、MIS、CRM应用）的Java平台，除了提供Java SE API外，还对其做了大量有针对性的扩充，这些扩展一般以javax.*作为包名，而以java.*为包名的包都是Java SE API的核心包，但由于历史原因，一部分曾经时扩展包的API后来进入了核心包中，因此核心包中也包含了不少javax.*开头的包名。除了这些扩充，还提供了相关的部署支持，这条产品线在JDK 6以前称为J2EE，在JDK 10以后被Oracle放弃，捐献给Eclipse基金会管理，此后被称为Jakarta EE。

JVM家族

Sun Classic VM

1996年1月23日Sun公司发布Java 1.0版本，该版本的JDK中所带的虚拟机就是Sun Classic VM，它同时也是世界上第一款商用Java虚拟机，JDK1.4时完全被淘汰。这款虚拟机内部只提供解释器。如果使用JIT编译器，就需要进行外挂。但是一旦使用JIT编译器，JIT就会接管虚拟机的执行系统。解释器就不再工作。解释器和编译器不能配合工作。在JDK1.2及之前，用户用classic虚拟机执行java -version 命令，将会看到类型下面这行的输出： java -version "1.2.2" Classic VM (build JDK-1.2.2-001，green threads，sunwjit) "sunwjit"（Sun Workshop JIT）就是SUN提供的外挂编译器，其他类似的还有Symant JIT和shuJIT等。 由于解释器和编译器不能配合工作，这就意味着如果要使用编译执行，编译器就不得不对每一个方法、每一行代码都进行编译，而无论它们执行的效率是否具有编译觉得价值。基于程序响应时间的压力，这些编译器根本不敢应用编译耗时稍高的优化技术，因此这个阶段的虚拟机虽然用了即时编译器输出本地代码，其执行效率也和传统的C/C++程序有很大差距，“java语言很慢”的印象就是在这阶段开始在用户心中树立起来的。

Exact VM

为了解决Classic VM的问题，JDK1.2时。sun提供了此虚拟机。它的编译执行系统已经具备现代高性能虚拟机雏形，如热点探测、两级即时编译器、编译器与解释器混合工作模式等。 Exact VM因它使用了准确式内存管理（Exact Memory Management，也可以叫Non-Conservative / Accurate Memory Management）而得名。准确式内存管理是指虚拟机可以知道内存中某个位置的数据具体是什么类型。 虽然Exact VM的技术比Classic VM先进很多，但在商业应用上只存在很短暂的时间就被外部引进的HotSpot VM所取代。而Classic VM的生命周期则相对要长，它在JDK1.2之前是JDK中唯一的虚拟机，在JDK1.2时，它与HotSpot VM并存，但默认是使用Classic VM（用户可用java -hotspot参数切换到HotSpot VM），而在JDK1.3时，HotSpot VM则成为默认虚拟机，它仍作为虚拟机的备用选择发布，使用 java -classic 参数切换，直到JDK 1.4 ，classic VM才完全退出商用虚拟机的历史舞台，与 Exact VM 一起进入Sun Labs Research VM 之中。

HotSpot VM

HotSpot VM 最初由一家名为“Longview technologies”的小公司设计。JDK1.3时，HotSpot VM则成为默认虚拟机。从那以后，默认的虚拟机都是HotSpot。Sun/Oracle JDK和Open JDK的默认虚拟机也是HotSpot。名称中的HotSpot 指的就是他的热点代码探测技术。通过计数器找到最具有编译价值的代码，触发即时编译或栈上替换，通过编译器与解释器协同工作，在最优化的程序响应时间与最佳执行性能中取得平衡。

BEA JRockit

JRockit 虚拟机号称是“世界上速度最快的Java虚拟机”，实际上，它和HotSpot、IBM J9这几大虚拟机的性能是交替上升的。他是BEA在2002从Appeal Virtual Machines公司收购获得的Java虚拟机。BEA将其发展为一款专门为服务器硬件和服务端应用场景高度优化的虚拟机，由于专注于服务端应用，它不太关注程序的启动速度，因此JRockit 内部不包含解释器实现，全部代码都靠即时编译器编译后执行。除此之外。JRockit的垃圾收集器和Java Mission Control故障处理套件等部分的实现，在当时众多的Java虚拟机中也处于领先水平。JRockit面向延迟敏感型应用的解决方案JRockit Real Time提供以毫秒或微秒级的JVM响应时间，适合财务、军事指挥、电信网络的需要；Java Mission Control服务套件，他是一组以极低的开销来监护、管理和分析生产环境中的应用程序的工具。 2008年，BEA被Oracle收购，Oracle计划整合两大优秀虚拟机，但是结果差强人意。Java Mission Control被移植到了HotSpot，作为收费功能提供给购买了Java SE Advanced产品计划的用户，其他功能由于两者架构的差异性明显，能够借鉴融合的功能寥寥无几。整合工作大概在JDK 8 完成。

IBM J9

全称：IBM Technology For Java Virtual Machine，简称IT4J，内部代号：J9。 市场定位和HotSpot接近，服务器端、桌面应用、嵌入式等多用途VM。开发J9的目的是作为IBM公司各种Java 产品的执行平台。2017年，IBM发布了开源J9 VM，命名为OpenJ9，交给Eclipse基金会管理，也称为Eclipse OpenJ9。

KVM和CDC/CLDC HotSpot

Oracle在java ME产品线上的两款虚拟机为：CDC-HI（C Virtual Machine）/CLDC-HI（Monty VM）,后面的HI则是 HotSpot Implementation 的缩写。 KVM中的K是“kilobyte”的意思，强调简单、轻量、高度可移植，但是运行速度比较慢。在Android、iOS等智能手机操作系统出现前曾经在手机平台上得到非常广泛应用。它是CLDC-HI早期产品。 Java ME中的Java虚拟机现在处于比较尴尬的位置，它最大的市场智能手机已经被Android和iOS二分天下。因为KVM的优点，在低端的设备上还维持字节的一片市场，例如智能控制器，传感器，老人手机以及经济欠发达地区的功能手机。

Azul VM

前面三大“高性能Java虚拟机”使用在通用硬件平台上，Azul VM和BEA Liquid VM是与特定硬件平台绑定、软硬件配合的专有虚拟机，是高性能Java虚拟机中的战斗机。 Azul VM是Azul System 公司在HotSpot基础上进行大量改进，运行于Azul System 公司的专有硬件Vega系统上的Java虚拟机。每个Azul VM实例都可以管理至少数十个CPU和数百GB内存的硬件资源，并提供在巨大内存范围内实现可控的GC时间的垃圾收集器、专有硬件优化的线程调度等优秀特性。 2010年Azul System公司开始从硬件转向软件，发布了自己的Zing JVM，可以在通用X86平台上提供接近于Vega系统的特性。

Liquid VM

高性能Java虚拟机中的战斗机，BEA公司开发，直接运行在自家Hypervisor系统上，是JRockit虚拟机的虚拟化版本。Liquid VM即是现在的JRockit VE（virtual edition），Liquid VM不需要操作系统的支持，或者说他自己本身实现了一个专用操作系统的必要功能，如线程调度、文件系统、网络支持等。由虚拟机越过通用操作系统直接控制硬件可以获得很多好处，如在线程调度时，不需要在进行内核态/用户态的切换，可以最大限度地发挥硬件的能力，提升Java程序的执行性能。随着JRockit 虚拟机终止开发，Liquid VM项目也停止了。

Apache Harmony

Apache也曾经推出过与JDK 1.5和JDK 1.6兼容的Java运行平台Apache Harmony。它是IBM和Intel联合开发的开源JVM，受到同样开源的OpenJDK的压制，SUN坚决不让Harmony获得JCP认证，最终于2011年退役，IBM转而参与OpenJDK。虽然目前并没有Apache Harmony 被大规模商用的案例，但是它的java类库代码吸纳进Android SDK。

Microsoft JVM

微软为了在IE3浏览器中支持Java Applets，开发了Microsoft JVM。只能在window平台下运行，但却是当前window下性能最好的java VM。1997年，SUN以侵犯商标、不正当竞争罪名指控微软成功。微软在windowsXP SP3中抹掉了其VM。现在window上安装的JDK都是HotSpot。

Taobao VM

由AliJVM 团队发布。覆盖云计算、金融、物流、电商等众多领域，需要解决高并发、高可用、分布式的复合问题。由大量的开源产品。它是基于OpenJDK HotSpot VM开发了自己的定制版本AlibabaJDK，简称AJDK。深度定制且开源的高性能服务器版Java虚拟机。 创新的GCIH（GC invisible heap）技术实现了off-heap，即将生命周期较长的java对象从heap中移到heap之外，并且GC不能管理GCIH内部的java对象，以此达到降低GC的回收频率和提升GC的回收效率的目的。GCIH中的对象还能够在多个java虚拟机进程中实现共享，使用了crc32指令实现JVM intrinsic 降低JNI的协调开销。PMU hardware 的Java profiling tool 和诊断协助功能。针对大数据场景的ZenGC。Taobao VM应用在阿里产品上性能高，但是硬件严重依赖intel的CPU，损失了兼容性，但是提高了性能。

Dalvik VM

谷歌开发的，应用于Android系统，并在Android2.2中提供了JIT，发展迅猛。Dalvik VM 只能称作虚拟机，而不能称作“Java虚拟机”，它没有遵循Java虚拟机规范，不能直接执行 Java的Class文件，是基于寄存器架构，不是JVM的栈架构。执行的是编译后的dex（Dalvik Executable）文件，执行的效率比较高。dex（Dalvik Executable）文件可以通过Class文件转化而来，使用Java语法编写应用程序，可以直接使用大部分的Java API。Android 5.0 使用支持提前编译（Ahead Of Time Compilation，AOT）的ART VM替换 Dalvik VM。

Graal VM

2018年4月，Oracle Labs公开了Graal VM，号称“Run ProgramsFaster Anywhere”，与1995年java的“Write Once，Run Anywhere”遥相呼应。Graal VM在HotSpot VM基础上增强而成的跨怨言全栈虚拟机，可以作为“任何语言”的运行平台使用。语言包括：Java、Scala、groovy、kotlin；C、C++、JavaScript、Ruby、Python、R等。支持不同语言中混用对方的接口和对象，支持这些语言使用已经编写号的本地库文件。工作原理是将这些语言的源代码或源代码编译后的中间格式，通过解释器转换为能被Graal VM接收的中间表示。Graal VM提供Truffle工具集快速构建面向一种新语言的解释器。在运行时还能进行即时编译优化，获得比原生编译器更优秀的执行效率。如果说HotSpot 有一天被取代，Graal VM希望最大。但是Java的软件生态没有丝毫变化。