JTechVault

Appearance

Apache Harmony / Microsoft / TaobaoJVM ​

历史的过客与国产的力量 ​

这一节聊聊那些「非主流」的 JVM 实现——有些是历史遗憾，有些是中国技术人的创新实践。

Apache Harmony：最接近 OpenJDK 的「另一个选择」 ​

背景 ​

2005 年，Apache 软件基金会收到了 Sun 的「邀请」：Apache Harmony 可以使用 Java 的商标，前提是遵守 TCK（Technology Compatibility Kit）认证。

但 Sun 很快反悔了，要求 Harmony 必须 100% 兼容 Java SE 的实现细节，而 Harmony 用的是自己写的代码，不是从 Sun 拿到的代码。

这场「许可战争」最终的结果是：Apache Harmony 被拒绝进入 Java SE 兼容认证，导致它始终只能是一个「类 Java」的实现，无法使用「Java」商标。

技术特点 ​

Apache Harmony 是一个完全从头实现的 Java SE 规范：

Apache Harmony（2005~2011）
├── DRLVM：自研的虚拟机内核
├── Apache Classlibs：重新实现的 Java 核心类库
└── 没有使用 Sun 的任何代码

DRLVM 的架构特点：

  • 兼容多种 JIT 引擎（自研 + 编码注入）
  • 支持增量 GC（Incremental GC）
  • 跨平台（Linux、Windows）
  • 模块化的类加载器设计

遗产 ​

2011 年，Apache Harmony 项目被投票关闭。它的遗产有两个：

  1. Google Android 的选择：Android 最初使用的 Dalvik VM，不是从 Sun 拿的代码，而是受 Harmony 的影响——都用自己实现的虚拟机和类库
  2. OpenJDK 的完善：Harmony 的某些设计思想被 OpenJDK 社区吸收

Harmony 的故事是一个关于「开放标准 vs 开放实现」冲突的经典案例。它证明了可以不依赖 Sun 的代码实现 Java，但也暴露了没有社区支持的开源项目难以与商业巨头竞争的残酷现实。

Microsoft JVM：曾经的血泪史 ​

Microsoft 的 Java 策略 ​

1996 年，Microsoft 拿到了 Sun 的 Java 许可，可以在 Windows 上分发 Java。但 Microsoft 的策略很明确：把 Java 变成 Windows 的绑定品，让 Java 开发者自然地依赖 Windows。

他们做了什么：

  • 微软版本的 JVM 在 Windows 上运行得更快（针对性优化）
  • 但添加了微软专有的扩展：DirectX 绑定、WFC（Windows Foundation Classes）
  • 这些扩展在标准 JVM 上无法运行

Sun vs Microsoft 的法律战 ​

1997 年，Sun 起诉 Microsoft违反 Java 许可协议。主要争议点：

  1. 不兼容的扩展：微软的 Windows 专用 API 在标准 JVM 上无法运行
  2. 延迟升级：Microsoft JVM 迟迟不升级到 Java 1.2，故意让微软版本看起来「更快」
  3. 商标侵权：微软在 Windows 上使用「Java 兼容」字样做营销

2001 年，双方和解。法院判决 Microsoft 停止在 Windows 中绑定 Java，并且不得分发不兼容的 Java 实现。

Microsoft JVM 的结局 ​

  • 2000 年：法院判决后，Microsoft 停止分发 Microsoft JVM
  • 2003 年：Microsoft JVM 彻底停止支持
  • Windows XP SP2：移除了 Microsoft JVM

Microsoft JVM 是商业竞争中技术被政治牺牲的案例。它在性能上曾经领先，但最终退出了历史舞台。

讽刺的是，Microsoft 退出 Java 领域后，大力发展了 C# 和 .NET CLR。多年后的 .NET Core（现在的 .NET）是一个跨平台的 .NET 实现——某种程度上，Microsoft 在 .NET 上实现了当年在 Java 上想做却没做到的事：跨平台运行。

给我们的教训 ​

Microsoft JVM 的教训很清晰：

  • 标准化需要社区共识：只有规范不够，还需要各方都愿意遵循
  • 商业利益可能与技术方向冲突：Microsoft 选择用自己的扩展绑定用户，最终在法律上失败
  • 开源不等于兼容：Harmony 证明了可以完全独立实现 Java，但没有 TCK 认证就没有「Java 兼容性」

TaobaoJVM：阿里对 JVM 的深度定制 ​

背景 ​

2010 年左右，阿里巴巴的 Java 应用规模已经非常大。团队发现 HotSpot 在超大规模部署下有一些痛点：

  • 启动慢：大型应用启动时间可能超过 30 秒
  • GC 不够稳定：高并发场景下 GC 停顿影响服务响应
  • 监控不足：原生工具不够用，需要更深入的运行时数据

于是，阿里的 JVM 团队对 HotSpot 进行了深度定制，诞生了 TaobaoJVM。

核心改进 ​

1. 极快的启动速度 ​

TaobaoJVM 在启动阶段做了大量优化：

  • Class Data Sharing（CDS）增强：预加载常用类到共享内存，启动时直接映射，省去重复加载
  • AppCDS：JDK 8 内置的 CDS 扩展，最早就是阿里向 OpenJDK 贡献的代码
  • 快速的字节码验证：跳过不必要的验证步骤
bash
# 启用 AppCDS
java -XX:+UseAppCDS -XX:+UnlockCommercialFeatures \
     -Xshare:auto -Xshare:dump MyApp

2. GCHardCoded 技术 ​

阿里团队发现，大多数 Java 应用的 GC 模式是可预测的。基于这个观察，他们开发了 GCHardCoded——通过预设的 GC 策略，减少动态调整的开销。

传统 GC：
  运行时检测 → 动态调整参数 → 可能不稳定

GCHardCoded：
  预设 GC 模式 → 严格按照预设执行 → 更稳定可预测

3. 深度的运行时监控 ​

TaobaoJVM 暴露了大量 HotSpot 没有暴露的内部指标：

  • 每个方法的 JIT 编译时间
  • 内联决策的详细信息
  • 锁竞争的热点分布
  • 对象的分配速率和生命周期

这些数据通过 Arthas（阿里开源的 JVM 诊断工具）的前身提供给开发者。

4. GraalVM 集成 ​

阿里是 GraalVM 的早期采用者之一。TaobaoJVM 在部分场景下集成了 Graal 编译器，取得了显著的性能提升。

遗产：贡献回社区 ​

TaobaoJVM 的很多改进最终贡献给了 OpenJDK：

  • AppCDS：JDK 10+ 成为标准功能
  • Java 层面的诊断 API：JVMTI 增强
  • Arthas：2018 年开源，成为 JVM 诊断的主流工具

TaobaoJVM 的现状 ​

目前 TaobaoJVM 已经不再维护。阿里内部的 JVM 团队转而使用 Dragonwell JDK（阿里巴巴的 OpenJDK 发行版）和 OpenJDK 社区。Dragonwell 在 OpenJDK 基础上做了很多针对阿里业务场景的优化，但保持了和 OpenJDK 的兼容性。

三者的对比 ​

项目类型现状启示
Apache Harmony独立实现 Java SE2011 年关闭开放标准 vs 开放实现的矛盾
Microsoft JVMWindows 专属实现2003 年停止商业竞争中技术被牺牲
TaobaoJVMHotSpot 深度定制不再维护（转 Dragonwell）大厂如何把定制回馈给社区

从这些历史中能学到什么 ​

  1. 兼容性很重要：即使你的实现更好，如果不兼容主流规范，用户也不会买单
  2. 社区的力量：Harmony 失败了，OpenJDK 成功了——开源需要社区的持续参与才能存活
  3. 大厂的责任：阿里把改进回馈给 OpenJDK 和 Arthas 开源，是正确的开源姿势
  4. 技术债务：Microsoft JVM 的历史说明，用专有扩展绑住用户，短期可能有效，长期必然被反噬

下一节，我们来看看这个系列的最后一篇：Dalvik / GraalVM，了解 Android 的选择，以及 JVM 的未来方向。

基于 VitePress 构建

Copyright © 2025-2026 JTechVault