Alibaba Dragonwell 是一款 OpenJDK 的发行版。OpenAnolis 是企业级的操作系统，企业级操作系统必然包含企业级应用的运行时。众所周知，红帽的 CentOS 发行版里面其实有红帽自己做的 JDK 发行版，这既是他们对自己运行时技术可控的自信，也是对用户负责，比如说 OpenJDK 出现任何问题，他们可以在发行版上做改动，去帮助用户解决问题。
Java企业应用
Java 一直是企业级最佳的选择，其中有很多原因，目前云原生环境下，它有非常成熟的容器化方案，有 Spring boot 这样的框架来帮助我们把应用打包成一个非常适合容器运行的模式。也有很多分布式的中间件，比如说 Spring cloud，可以帮助我们构造分布式应用。Java也有非常好的规范以及开源生态，但 Oracle 虽然控制着 Java，同时也推进着Java标准往前演进，标准使得语言一直是可以控制的方向发展，非常适合开发企业级应用。里面有非常繁荣的生态，比如 Maven 可以帮助开发者快速获得开发依赖，还有Netty、Tomcat、Spring。虽然 Spring 可以看做是挑战 Jakarta EE的角色，但是它本身也受到 Java 的很多影响，因此可以说是Jakarta EE也在帮助Spring发展。
高效，运行时的高效和开发时的高效。运行时的高效体现在 Java 的执行速度，一个数据是 Java 的运行效率可以排在各大编程语言第四，效率可以达到 C 语言的二分之一，这在高级语言里非常难得的。
最后是行业实践，在互联网金融等行业里大规模使用 Java。
大家认为硬件+操作系统+应用就构成整个应用，其实运行时对于应用的运行影响是非常大的，通过一个例子解释。
这是我们在企业客户里遇到的一个问题，在 Java 运行时开始很好，经过一天以后性能就变成 1/2，越来越慢，只能选取变慢的实例重启，他能做的就是把变慢的实例直接重启或者是扩容，因为变慢后需要更多的机器支撑容量。但这并不解决问题，因为变慢这个行为持续在发生。
最后排查出是 JIT 相关问题， Java应用有 JIT 编译器，也有解释模式，我可以给大家一个数字，编译模式要比解释模式快 50 倍左右，所以有部分代码执行在解释模式的话，影响非常大，假如有 2% 的代码在解释器模式，则整个应用一半的时间在执行解释器，一半的时间在执行编译器，性能下降一倍。假如说一半的代码退到解释器，那应用就会慢 25 倍左右，所以运行时对应用有深远影响。
阿里巴巴 Dragonwell 和 Eclipse Temurin 都是 OpenJDK 的开源发行版本，为什么近年来除了谷歌以外所有的头部云厂商都推出了自己的发行版。自 OpenJDK9 开始，每半年发布一个版本，这个版本只会维护一年，比如说 OpenJDK 从 2018 年 3 月开始维护到 2019 年 3 月，中间只有一年的维护时间，选取这样的策略是因为 OpenJDK9 引入了很多新的特性，比如说模块化，对开发进程影响非常大，所以选取了这样一种滚动升级策略。
假如我们的用户想去使用最新的JDK，那他必须接受滚动升级。比如说现在Java已经到了17了，五年后Java会到达27的版本，这样的升级频率肯定是接受不了的。假设Java用户停留在老版本是不是可以避免这种滚动升级？实际也不行， Java远程执行漏洞非常多，我们可以通过序列化构造一些远程代码执行的例子，这是非常可怕的。各个云厂商都提供了自己的OpenJDK发行版，想获得Oracle也是可以的，是收费的。
阿里巴巴Dragonwell就是在这种背景下产生出了Java运行时，我们完全依托开源社区建设，我们参与了非常多国际上的高质量社区，现在也加入了龙蜥社区，其中包括Java的JCP-EC，阿里巴巴是国内唯一一个加入EC席位的企业(EC的全称是执行委员会)。
Alibaba Dragonwell是在OpenJDK的基础上增加了一些自己的功能，构成了阿里巴巴Dragonwell发行版本。我们会发布稳定的发行版本，并且提供定期的安全补丁，质量体系接轨国际，基于Adoptium的CI，Adoptium组织由各个JDK的头部厂商维护，包括微软、IBM都参与其中。经过测试以后，我们会在阿里巴巴线上验证；SVT系统验证，会用spring等常用框架进行验证我们的JDK。我们也支持多平台，比如Linux、windows；RISC-V架构的支持也已经提上日程。
和Java企业计算相关的另外一个发行版是Eclipse Temurin，它源自AdoptOpenJDK。AdoptOpenJDK是怎么来的？可以看到前面的Oracle发布策略，大家使用OpenJDK会越来越困难，所以伦敦的Java User Group创建AdoptOpenJDK项目，让OpenJDK可以方便地被用户使用。该项目编译OpenJDK的source code，经过aqa-tests才会release出来，可以说是原汁原味的OpenJDK。和Alibaba Dragonwell的差异是：上一页有一块Dragonwell补丁，而Temurin是原汁原味的OpenJDK。
Aqa-tests包括性能测试，OpenJDK自带测试。其中的system测试会验证Java的模块化系统，Java的自带工具等。后面是external，包括Java生态里面常见的一些软件，像scala、kafka。最后是标准的JCK，Oracle所颁布的一个标准，只要JDK发行版跑过验证就是标准的JDK。
很多传统企业用户不需要阿里巴巴Dragonwell里面为云或者互联网设计的功能，他可以选择Eclipse Temurin发行版。
让我们看看使用这两个发行版企业可以获得什么。
- 安全特性，Java的TSL能力是通过JSSE接口使用的，Eclipse Temurin和Alibaba Dragonwell的JSSE能力都会经过验证，这对企业用户是非常重要的
- 兼容性，Dragonwell基于OpenJDK而Temurin是原汁原味的OpenJDK，从OracleJDK迁移到OpenJDK可以保证兼容性。
- Java生态的集成验证
- 定期安全补丁，Alibaba Dragonwell或者Eclipse Temurin，这两个发行版是完全以完全开源的形式运作的。我们会以每三个月一次的固定发行周期提供订阅支持。
Alibaba Dragonwell上有很多阿里巴巴自己扩展的云原生特性，通过这些特性我们可以轻易的排查问题或者轻易的减少资源使用，或者是降低总体成本，这是Eclipse Temurin和OracleJDK所没有的。
基于这两个JDK发行版本我们提供了企业服务体系。如果企业用户从OracleJDK某个版本迁移过来，首先面临的问题是迁移。Java的版本迁移不像GO或者其他语言那样轻松，比如JDK8迁移到11或者17，都有很大的迁移工作量。我们提供迁移了工具，并积累了许多迁移经验文档给到企业去迁移到Eclipse Temurin或者Alibaba Dragonwell。
Java由于庞大的类库会隐含很多的安全问题。如果选择订阅了Alibaba Dragonwell企业支持服务，会获得每三个月的推送，对于一些重大更新我们会进行评估，是否是重要更新，是否要升级，升级计划是什么。
应急支撑体系是IT企业的日常需求，在Java使用中只要上了规模都会有无法预期的问题。这里我们提供了7×24小时的专属钉钉或者电话支持，响应时间保证到在业务不可用情况下10分钟响应，业务一般的问题在一小时可以获得响应，主要城市可以两小时内得到到达现场的服务。
我们结合之前的案例来看，用户通过我们的服务能获得怎样的体验。首先用户发现并报告了问题，由于北京是主要城市，两小时内可以到达现场。随后我们帮助用户保存现场，分析问题，定位问题，最后交付服务。
代码空间满导致代码部分解释执行，从而性能变差，但代码空间满依旧不是根因。一步步深入定位，分析出原因： 因为用户从低版本JDK升上来，低版本JDK的代码回收功能是有问题的，因此用户禁用了代码空间的回收功能。随着应用持续运行，编译代码越来越多，如果开启了代码空间的回收，失效代码是可以被Java虚拟机回收的。但是用户关闭了代码空间回收，最终导致代码空间满。Hotspot虚拟机在代码空间满时策略是禁止JIT编译。
确认问题后帮助用户在少量机器上验证，确认修复完成后交付服务，书面给与用户确认。
原文链接：
本文为阿里云原创内容，未经允许不得转载。
