CH01-走近 Java

Java 技术体系

Java 技术体系包括以下几个组成部分：

  • Java程序设计语言
  • 各种硬件平台上的Java虚拟机
  • Class文件格式
  • Java API类库
  • 来自商业机构和开源社区的第三方Java类库

我们可以把Java程序设计语言、Java虚拟机、Java API类库这三部分统称为JDK（Java Development Kit），JDK是用于支持Java程序开发的最小环境，在后面的内容中，为了讲解方便，有一些地方会以JDK来代替整个Java技术体系。另外，可以把Java API类库中的Java SE API子集和Java虚拟机这两部分统称为JRE（Java Runtime Environment），JRE是支持Java程序运行的标准环境。图1-2展示了Java技术体系所包含的内容，以及JDK和JRE所涵盖的范围。

NAME

以上是根据各个组成部分的功能来进行划分的，如果按照技术所服务的领域来划分，或者说按照Java技术关注的重点业务领域来划分，Java技术体系可以分为4个平台，分别为：

  • Java Card：支持一些Java小程序（Applets）运行在小内存设备（如智能卡）上的平台。
  • Java ME（Micro Edition）：支持Java程序运行在移动终端（手机、PDA）上的平台，对Java API有所精简，并加入了针对移动终端的支持，这个版本以前称为J2ME。
  • Java SE（Standard Edition）：支持面向桌面级应用（如Windows下的应用程序）的Java平台，提供了完整的Java核心API，这个版本以前称为J2SE。
  • Java EE（Enterprise Edition）：支持使用多层架构的企业应用（如ERP、CRM应用）的Java平台，除了提供Java SE API外，还对其做了大量的扩充并提供了相关的部署支持，这个版本以前称为J2EE。
NAME

虚拟机发展史

  • Sun Classic/Exact VM，只能使用纯解释方式来执行 Java 代码，如果需要使用 JIT 编译期，就需要进行外挂。一旦外挂 JIT，解释器便被完全接管。
  • Exact VM，已具备现代高性能虚拟机的雏形，具备两级即时编译期、编译期与解释器混合工作模式，使用精准式内存管理。
  • HotSpot，名称指的是热点代码探测技术，准确式 GC。
  • Sun Mobile-Embedded VM/Meta-Circular VM
  • JRockit VM，专注于服务器端应用，它可以不太关注程序启动速度，因此内部不包含解析器实现，全部代码都靠即时编译器编译后执行。除此之外，J垃圾收集器和MissionControl服务套件等部分的实现，在众多Java虚拟机中也一直处于领先水平。
  • IBM J9 VM，它是一款设计上从服务器端到桌面应用再到嵌入式都全面考虑的多用途虚拟机，J9的开发目的是作为IBM公司各种Java产品的执行平台，它的主要市场是和IBM产品（如IBM WebSphere等）搭配以及在IBM AIX和z/OS这些平台上部署Java应用。
  • Azul VM，基于 HotSpot 改进，用于专有硬件Vega系统上的 Java 虚拟机，每个 Azul 实例可与管理至少数十个 CPU 和数百GB内存的硬件资源，并提供在巨大内存范围内实现可供 GC 时间的垃圾回收器，为专有硬件优化的线程调度。
  • BEA Liquid VM，即现在的 JRockit VE，不需要操作系统的支持，自身实现了一个专用操作系统的必要功能。由虚拟机越过通用操作系统直接控制硬件可以获得很多好处，如在线程调度时不需要进程内核态/用户态的切换等，以最大限度的发挥硬件的能力。
  • Apache Harmony，很多优秀代码被吸纳进 JDK 7 和 Google Android SDK 中，尤其对 Android 的发展起到了很大的推动作用。
  • Google Android Dalvik VM，Andriod 平台的核心组件，不遵循 JVM 规范，不能直接执行 Class 文件，使用的是寄存器架构而非 JVM 中常见的架构。其执行文件可以通过 Class 文件转化而来，可以使用 Java 来编写应用并调用大部分的 Java API。随着 Android 的迅猛发展得以快速发展。
  • Microsoft JVM，Windows 平台特定 JVM，最终因侵权终止。
  • GraalVM，支持多种编程语言的通用虚拟机，低负载、高性能。

热点代码探测能力可以通过执行计数器找出最具有编译价值的代码，然后通知JIT编译器以方法为单位进行编译。 如果一个方法被频繁调用，或方法中有效循环次数很多，将会分别触发标准编译和OSR（栈上替换）编译动作。通过编译器与解释器恰当地协同工作，可以在最优化的程序响应时间与最佳执行性能中取得平衡，而且无须等待本地代码输出才能执行程序，即时编译的时间压力也相对减小，这样有助于引入更多的代码优化技术，输出质量更高的本地代码。

未来展望

  • 模块化。解决应用系统与技术平台越来越复杂、越来越庞大的一个重要功能。
  • 混合语言。当单一的Java开发已经无法满足当前软件的复杂需求时，越来越多基于Java虚拟机的语言开发被应用到软件项目中，Java平台上的多语言混合编程正成为主流，每种语言都可以针对自己擅长的方面更好地解决问题。
  • 多核并行。ForkJoin 和 Lambda 帮助 Java 顺利过渡到多核，对多核的深入支持有助于稳定 Java 的引领低位。
  • 丰富语法。
  • 64 位虚拟机。由于指针膨胀和各种数据类型对齐补白的原因，运行于64位系统上的Java应用需要消耗更多的内存，通常要比32位系统额外增加10%～30%的内存消耗；其次，多个机构的测试结果显示，64位虚拟机的运行速度在各个测试项中几乎全面落后于32位虚拟机，两者大约有15%左右的性能差距。

源码结构

NAME

如何阅读 HotSpot 源码

RednaxelaFX: 为啥别读 HotSpot VM 的源码

什么时候不读 HotSpot 源码

  • 不同 JVM 具体实现相当复杂。
  • 基础概念不扎实时。
    • 硬读实现复杂的源码对理解基础概念的帮助不大。
    • 繁琐的实现细节反而会掩盖一些抽象概念。
  • 已有现成的阅读资料时。
    • 读资料比读源码更容易吸收自己需要的信息。
    • 因人而异。

不明就里读源码的坏处

  • 加深误解
  • 浪费时间/精力
    • 读了但全然无法理解，还不如先不读
    • 有些细节知道了也没用

在读源码之前

  • 仅为理解 Java 程序的行为？
    • 是否已经了解 Java 语言层面的规定？
      • Java 语言规范
    • 是否已经了解 JVM 的抽象概念？
      • JVM 规范
    • 已确定需要关注的行为是特定与某个实现？
      • 回到上面两点
    • 是否有关于该实现的内部细节的文字描述？
      • 优先选择阅读文字描述。
  • 仍然想深入学习 VM 的内部知识？
    • 阅读相关背景知识的书、论文、博客等。
      • 能够在阅读源码之前事先了解术语。
      • 知道术语便于找到更多资料。
    • 阅读一些更加简单的 VM 实现的源码。
      • 循序渐进。
    • 自己动手编写简单的编译器、VM
      • 实践是检验真理最有效途径。
    • 最后，如果真的有空才去读 HotSpot 源码。
  • 工作的内容就是开发 HotSpot VM？
    • 需要非常仔细的阅读。
    • 优先选择动态调试。
    • 上手顺序：文档——读代码——做实验——调试。

其他 VM

  • KVM：简单小巧的 JVM 实现。
    • 优点：
      • 包含 JVM 的最核心组件
      • 实现方式与 JVM 规范所描述的抽象比较接近
    • 缺点：
      • 是 Java ME CLDC VM，而不是 Java SE VM
      • 未实现反射、浮点计算等功能
  • Maxine VM：纯 Java 实现的 JVM。
    • 可在 IDE 中开发调试
    • 二进制兼容性，可使用 Oracle JDK/OpenJDK 的类库，兼容主流的 Java 应用。
  • VMKit/J3：使用线程组件搭建的 JVM。

其他资源