第1章 走近Java
（一）Java技术体系
包括：
- Java程序设计语言
- 各种硬件平台上的Java虚拟机实现
- Class文件格式
- Java类库API
- 来自商业机构和开源社区的第三方Java类库
JDK
Java程序设计语言 + Java虚拟机 + Java类库 = JDK
JRE + 开发工具API = JDK
是用于支持Java程序开发的最小环境
JRE
Java SE API子集 + Java虚拟机 = JRE
JRE是支持Java程序运行的标准环境
JVM
运行Java程序的核心虚拟机
Java SE
支持面向桌面级应用的Java平台，提供了完整的Java核心API
这条产品线在JDK 6以前被称为J2SE。
Java EE
支持使用多层架构的企业应用（如ERP、MIS、CRM应用）的 Java平台
除了提供Java SE API外，还做了大量的扩充，并提供了相关的部署支持
这条产品线在JDK 6以前被称为J2EE
在JDK 10以后被Oracle放弃，捐献给Eclipse基金会管理，被称为Jakarta EE
（二）Java虚拟机大家族
Sun Classic VM
- “世界上第一款商用Java虚拟机”，已经淘汰
- 只能使用纯解释器方式来执行Java代码
Exact VM
- 准确式内存管理（Exact Memory Management）
- 虚拟机可以知道内存中某个位 置的数据具体是什么类型，这也是在垃圾收集时准确判断堆上的数据是否还可能被使用的前提。
- 已经淘汰
HotSpot VM
- 是Sun/OracleJDK和OpenJDK中的默认Java虚拟机，也是目前使用范围最广的Java虚拟机。官方JDK均采用HotSpot VM。
- 非由Sun公司所开发
JRockit
- BEA公司开发，是世界上最快的Java虚拟机
- 专注于服务端应用，全部靠编译器执行。
J9
- IBM开发。
- J9虚拟机的职责分离与模块化做得比HotSpot更优秀，由J9 虚拟机中抽象封装出来的核心组件库（包括垃圾收集器、即时编译器、诊断监控子系统等）就单独构 成了IBM OMR项目，可以在其他语言平台如Ruby、Python中快速组装成相应的功能。
Azul VM
- 是专有虚拟机，在HotSpot基础上进行大量改进的成果。
- 每个Azul VM实例都可以管理至少数十个CPU和数百GB的内存的硬件资 源，并提供在巨大内存范围内停顿时间可控的垃圾收集器。
Liquid VM
- 专有虚拟机，JRockit虚拟机的虚拟化版本
- Liquid VM不需要操作系统的支持，或者说它自己本身实现了一个专用操作系统的必要功能
……
（三）其他零碎点
对需要长时间运行的应用来说，由于经过充分预热，热点代码会被HotSpot的探测机制准确定位捕获，并将其编译为物理硬件可直接执行的机器码，在这类应用中Java的运行效率很大程度上取决于即 时编译器所输出的代码质量。
HotSpot虚拟机中含有两个即时编译器，分别是编译耗时短但输出代码优化程度较低的客户端编译器（简称为C1）以及编译耗时长但输出代码优化质量也更高的服务端编译器（简称为C2），通常它们 会在分层编译机制下与解释器互相配合来共同构成HotSpot虚拟机的执行子系统（这部分具体内容将在 本书第11章展开讲解）。
对不需要长时间运行的，或者小型化的应用而言，Java（而不是指Java ME）天生就带有一些劣势，这里并不只是指跑个HelloWorld也需要百多兆的JRE之类的问题，更重要的是指近几年在从大型单体应用架构向小型微服务应用架构发展的技术潮流下，Java表现出来的不适应。
在微服务架构的视角下，Java的启动时间相对较长，需要预热才能达到最高性能等特点就显得相悖于这样的应用场景。而酝酿中的一 个更彻底的解决方案，是逐步开始对提前编译（Ahead of Time Compilation，AOT）提供支持。
提前编译是相对于即时编译的概念，提前编译能带来的最大好处是Java虚拟机加载这些已经预编 译成二进制库之后就能够直接调用，而无须再等待即时编译器在运行时将其编译成二进制机器码。理论上，提前编译可以减少即时编译带来的预热时间，减少Java应用长期给人带来的“第一次运行慢”的不良体验，可以放心地进行很多全程序的分析行为，可以使用时间压力更大的优化措施[。
但是提前编译的坏处也很明显，它破坏了Java“一次编写，到处运行”的承诺，必须为每个不同的 硬件、操作系统去编译对应的发行包；也显著降低了Java链接过程的动态性，必须要求加载的代码在 编译期就是全部已知的，而不能在运行期才确定，否则就只能舍弃掉已经提前编译好的版本，退回到 原来的即时编译执行状态。