科普文：【支持信创、宣传国产】ARM上最好用的JDK之毕昇JDK_业界新闻

发布时间:2024-08-31 13:42

阅读量:0

概叙

毕昇JDK是华为内部基于OpenJDK定制的Huawei JDK的开源版本。Huawei JDK运行在华为内部500多个产品上，研发团队积累了丰富的开发经验，解决了业务实际运行中遇到的多个疑难问题。

毕昇JDK作为OpenJDK的下游，是一款高性能、可用于生产环境的OpenJDK发行版。毕昇JDK对华为内部应用场景中遇到的一些性能问题和稳定性问题进行了修复，并在ARM架构上进行了性能优化和稳定性增强，在ARM架构上更稳定，在大数据等场景下可以获得更好的性能。

毕昇JDK致力于为JAVA开发者提供一款稳定可靠、高性能、易调测的JDK，也为用户在ARM架构上提供一个更好的选择。

更多信息：

License: 采用GPLv2 with Classpath Exception协议。
支持Java版本: 目前毕昇JDK支持8、11、17、21四个LTS版本。
支持架构: 支持Linux/AArch64、Linux/x86_64架构。
支持操作系统: 目前仅支持Linux版本，对操作系统的要求glibc版本不低于2.18，基本覆盖所有主流操作系统，发布前经过稳定性验证的操作系统有openEuler 全系列操作系统、CentOS 7.6、Ubuntu 20.04、Ubuntu 22.04、麒麟V10和UOS 20

毕昇JDK整体架

JDK整体架构如下图所示，其中JRE指的是Java Runtime Environment，包括了Java运行时的虚拟机JVM（Java Virtual Machine）、Libraries等。而JDK是JRE的超集，包括了JRE的所有内容，并包含javac、jdb等开发者必须的编译器和调试器。JRE仅提供运行时库、Java虚拟机和其他一些运行Java应用程序所必须的组件。

参考Hotspot VM

Hotspot VM设置模式 默认情况Hotport VM采用的是解释器和JIT编译器并存的架构，也可以根据使用场景使用命令行设置完全使用解释器或者JIT编译器执行：  -Xint:完全采用解释器执行。 -Xcomp:完全采用JIT编译器执行，如果编译时出现问题，解释器会介入。 -Xmixed:采用混合模式执行。  JIT编译器的分类，Hotpot VM内置了两种JIT编译器，分别为Client Compiler和Server Compiler，简称C1和C2编译器，默认情况都是Server模式，可以使用命令显式指定模式：  -client:C1编译器会对字节码进行简单和可靠的优化，耗时短，有更快的编译速度。 -server:C2编译器进行**耗时较长的优化，以及激进的优化。**但代码执行效率更高。64位操作系统固定这个编译器。  C2编译器的优化如下几种：  标量替换：用标量值代替聚合对象的属性值。 栈上分配：对于未逃逸的对象分配对象在栈上而不是堆上。 同步消除：清楚同步操作，通常是synchronized。

毕昇JDK使用的JVM不是J9

毕昇JDK是由华为公司基于OpenJDK维护的开源免费JDK，‌而J9是IBM产的JVM。‌

虽然毕昇JDK是基于OpenJDK的开源项目，‌但并不意味着它使用了J9作为其JVM实现。‌

华为在开发毕昇JDK时，‌可能选择了其他兼容且优化的JVM实现，‌以提供更好的性能和稳定性给用户。‌因此，‌毕昇JDK与J9是两种不同的JVM实现，‌尽管它们都基于OpenJDK源代码进行开发。

5款主要的JVM

JVM(Java 虚拟机)目前主要是这4个. 微软JVM死了N多年了,GCJ支持到1.4.2之后,处于停滞状态.现在市面上能见到的,也就是这4种.

HotSpot VM

HotSpot VM是绝对的主流。大家用它的时候很可能就没想过还有别的选择，或者是为了迁就依赖了Oracle/Sun JDK某些具体实现的烂代码而选择用HotSpot VM省点心。

Oracle / Sun JDK、OpenJDK的各种变种（例如IcedTea、Zulu），用的都是相同核心的HotSpot VM。从Java SE 7开始，HotSpot VM就是Java规范的“参考实现”（RI，Reference Implementation）。把它叫做“标准JVM”完全不为过。

当在面试中问道“Java性能如何如何”、“Java有多少种GC”、“JVM如何调优”等等，默认问的就是特指HotSpot VM，可见其“主流性”。（其实这不是件好事，可能有些面试官自己都不知道VM需要分类，当我们讨论与JVM相关的问题是还是要具体到哪个VM才正确严禁）

JDK8的HotSpot VM已经是以前的HotSpot VM与JRockit VM的合并版，也就是传说中的“HotRockit”，只是产品里名字还是叫HotSpot VM。这个合并并不是要把JRockit的部分代码插进HotSpot里，而是把前者一些有价值的功能在后者里重新实现一遍。移除PermGen、Java Flight Recorder、jcmd等都属于合并项目的一部分。

不过要留意的是，这里我说的HotSpot VM特指“正常配置”版，而不包括“Zero / Shark”版。Wikipedia那个页面上把后者称为“Zero Port”。用这个版本的人应该相当少，很多时候它的release版在其指定OS上都build不成功！

提起HotSpot VM，相信所有Java程序员都知道，它是Sun JDK和OpenJDK中所带的虚拟机，也是目前使用范围最广的Java虚拟机。  但不一定所有人都知道的是，这个目前看起来“血统纯正”的虚拟机在最初并非由Sun公司开发，而是由一家名为“Longview Technologies”的小公司设计的；  甚至这个虚拟机最初并非是为Java语言而开发的，它来源于Strongtalk VM， 而这款虚拟机中相当多的技术又是来源于一款支持Self语言实现“达到C语言50%以上的执行效率”的目标而设计的虚拟机，  Sun公司注意到了这款虚拟机在JIT编译上有许多优秀的理念和实际效果， 在1997年收购了Longview Technologies公司，从而获得了HotSpot VM。 HotSpot VM既继承了Sun之前两款商用虚拟机的优点（如前面提到的准确式内存管理），也有许多自己新的技术优势， 如它名称中的HotSpot指的就是它的热点代码探测技术（其实两个VM基本上是同时期的独立产品， HotSpot还稍早一些，HotSpot一开始就是准确式GC， 而Exact VM之中也有与HotSpot几乎一样的热点探测。  为了Exact VM和HotSpot VM哪个成为Sun主要支持的VM产品，在Sun公司内部还有过争论， HotSpot打败Exact并不能算技术上的胜利）， HotSpot VM的热点代码探测能力可以通过执行计数器找出最具有编译价值的代码，然后通知JIT编译器以方法为单位进行编译。 如果一个方法被频繁调用，或方法中有效循环次数很多，将会分别触发标准编译和OSR（栈上替换）编译动作。 通过编译器与解释器恰当地协同工作，可以在最优化的程序响应时间与最佳执行性能中取得平衡，而且无须等待本地代码输出才能执行程序， 即时编译的时间压力也相对减小，这样有助于引入更多的代码优化技术，输出质量更高的本地代码。 在2006年的JavaOne大会上，Sun公司宣布最终会把Java开源，并在随后的一年，陆续将JDK的各个部分（其中当然也包括了HotSpot VM）在GPL协议下公开了源码， 并在此基础上建立了OpenJDK。这样，  HotSpot VM便成为了Sun JDK和OpenJDK两个实现极度接近的JDK项目的共同虚拟机。 在2008年和2009年，Oracle公司分别收购了BEA公司和Sun公司，这样Oracle就同时拥有了两款优秀的Java虚拟机：JRockit VM和HotSpot VM。  Oracle公司宣布在不久的将来（大约应在发布JDK 8的时候）会完成这两款虚拟机的整合工作，使之优势互补。 整合的方式大致上是在HotSpot的基础上，移植JRockit的优秀特性，譬如使用JRockit的垃圾回收器与MissionControl服务， 使用HotSpot的JIT编译器与混合的运行时系统。

Exact VM（暂不提）

这是一款被HotSpot VM给PK掉的VM，上面讲历史的时候讲过。它只存在了很短暂的时间，而且只在Solaris平台发布过。

Sun JVM

Sun公司的产品,也是平时用得最多的.一提到JVM,很多人自然就想到SUN的Java虚拟机.其实不然,Java现在已经可以看成一种"事实上"的标准.就和C,C++一样.Sun的虚拟机特点:中规中矩,最标准,应用平台最多.

JRocket

JRocket是BEA公司的JVM,号称世界上最快的JVM.这款虚拟机其实也很常见.使用WebLogic的用户,往往使用JRocket虚拟机. 因为其内存回收算法的特别,理论上据说使得JRocket在Windows平台上的表现要比Sun Java好一些.但是偶的感觉是,在Linux下,JRocket表现得没有Sun Java稳定(有时会莫名其妙down掉).至于JRocket号称的快速,我倒从没感觉出来过. 这款虚拟机是商业产品,但是可以免费使用.它自带的"JRocket 控制台",做得很不错.

JRockit VM曾经号称“世界上速度最快的Java虚拟机” 。由于专注于服务器端应用，它可以不太关注程序启动速度，因此JRockit内部不包含解析器实现，全部代码都靠即时编译器编译后执行。

除此之外，JRockit的垃圾收集器和MissionControl服务套件等部分的实现，在众多Java虚拟机中也一直处于领先水平。这一套思想已经在Java 8中被HotSpot VM给用上了。

BEA已经被Oracle收购了,所以准确地说,现在是Oracle的产品

J9

IBM产的JVM,也号称过世界上最快的Java虚拟机. 我没感受过它的快,只觉得这个玩意儿超级不稳定(IBM软件的通病). 和Websphere 应用服务器配合使用,倒是很少出差错.但是换了普通Java程序,就10有八九出问题了.

也有人告诉我,这个虚拟机跑在AIX大机上是很稳定的,Windows下根本不能用,也许吧.IBM做的软件,永远是那德行.

J9是IBM开发的一个高度模块化的JVM，这也是我们在工作中可能会用到的另外一个VM（除了这两个，在中国的大厂里不大可能接触到其他的了）。

在许多平台上，IBM J9 VM都只能跟IBM产品一起使用。这不是技术限制，而是许可证限制。例如说在Windows上IBM JDK不是免费公开的，而是要跟IBM其它产品一起捆绑发布的；使用IBM Rational、IBM WebSphere的话都有机会用到J9 VM（也可以自己选择配置使用别的Java SE JVM）。

根据许可证，这种捆绑在产品里的J9 VM不应该用于运行别的Java程序，但是大家自己“偷偷的”拿来跑别的程序，IBM也没力气管。而在一些IBM的硬件平台上，很少客户是只买硬件不买配套软件的，IBM给一整套解决方案，里面可能就包括了IBM JDK。这样自然而然就用上了J9 VM。所以J9 VM得算在主流里，虽然很少是大家主动选择的首选。

J9 VM的性能水平大致跟HotSpot VM是一个档次的。有时HotSpot快些，有时J9快些。不过J9 VM有一些HotSpot VM在JDK8还不支持的功能，最显著的一个就是J9支持AOT编译和更强大的class data sharing。

Harmony

IBM和Intel搞的开源JVM. IBM牵头,不过主力是Intel.为此Intel去年在国内还大张旗鼓招聘Java程序员.C部分的代码不消说,就算是Java部分的代码,也是Intel在努力搞. 这玩意儿纯粹是IBM-Intel和SUN扯皮的结果.想借此获得Java世界的话语权. IBM利用Harmony来攻击Sun的不开源,结果Sun把Java在GPL协议下开源之后,IBM又攻击SUN把Java "不负责任地开源"---只有Harmony用Apache License协议才是合适的.Sun也借此反击,坚决不让Harmony获得JCP认证.....口水战满天飞,苦的是Intel.目前版本是5.0M4,正式版遥遥无期. (Harmony着实要比J9好,至少兼容性要好多!)

墙里开花墙外香,Harmony在Java时间里一直没取得名分,独守空房地时候,被Google看中,作为其手机操作系统Android里的虚拟机.

由此,Java世界里第二次事实上的分裂终于出现(j++到.NET的发展,偶觉得可以看做是第一次分裂).

Harmony在Android里修成正果.虽然语法是99%的Java语法,但是字节码结构,连接模型..这些JCP标准里定义的东西,已经完全对不上号.这就好比我们写着J#.NET---即便语法是Java的.