您的位置:首页 > 编程语言 > Java开发

毕昇JDK,重现了 “活字印刷术” 的传奇

2020-11-10 18:44 1091 查看

毕昇JDK,重现了 “活字印刷术” 的传奇






中央处理器,即CPU,包含很多种设计架构。其中最常见的架构有两种,一种是X86架构,一种是ARM架构。

这两种架构有什么不同呢?主要是使用的指令集不一样。

X86架构使用CISC指令集,即复杂指令集,最典型的代表就是英特尔处理器。

ARM架构使用RISC指令集,即精简指令集,华为的鲲鹏就是基于ARM架构。

OpenJDK,对于X86架构处理器有很好的支持,虽然也基本支持ARM架构处理器,但是在性能上并不理想。

正是为了弥补OpenJDK在ARM架构上运行的劣势,华为开源了自己研发的JDK发行版,并贡献到openEuler 开源社区,这就是咱们提到的Bisheng JDK。



优化1:增加AppCDS的支持

AppCDS,是Java当中的一个新特性,全称是Application Class-Data Sharing。

要解释这个特性,就不得不先讲解一下Java的类加载过程。

众所周知,JVM会把你写的每一行Java代码都编译成字节码,存储在class文件当中。在运行时,JVM会加载这些class文件,并解释执行。

Java的默认类加载器有三种,层次从高到低,分别是BootstrapClassLoader,ExtClassLoader,AppClassLoader。

启动JVM的时候,进行类加载工作会占用一定的时间。

如果我们同时运行多个Java进程,也就是启动了多个JVM,每一个JVM都重复加载许多相同的字节码,会浪费许多无谓的时间:

如果我们能在JVM第一次成功加载这些class之后,把class的信息归档到一个共享空间中,让其他的JVM也能直接获取到这些加载完成的class信息,岂不是节省了很多时间?

早在JDK1.5版本,Java团队就给出了类似的解决方案,这个特性叫做CDS(Class-Data Sharing)。

可惜的是,CDS这个特性只局限于BootstrapClassLoader层级的class-data共享,虽然也带来了一定的性能优化,但是杯水车薪。

后来,Java团队把class-data共享的范围扩展到了AppClassLoader这个层级,这就是所谓的AppCDS。

AppCDS为JVM的类加载带来了明显的性能优化,但仍然有一点美中不足:AppCDS是Oracle JDK8的收费商用特性,在OpenJDK8当中并不支持。

幸好Bisheng JDK团队解决了这个问题,使得鲲鹏上面运行的Java代码也能享受到AppCDS带来的性能优化。

目前,该优化针对的版本是Bisheng JDK 8。

优化2:增加ZGC的支持

GC,即垃圾回收机制,做过Java的小伙伴恐怕没有人不知道。

JVM垃圾回收,面临的最大痛点是什么呢?毫无疑问,是回收过程中用户线程的停顿。

为了解决这个痛点,尽量缩短停顿时间,Java团队做了很多的努力,各种各样的垃圾回收器随之诞生,比如Serial,Parallel,CMS,G1......

在JDK11中,又一种全新的垃圾回收器诞生了,这种垃圾回收器叫做ZGC。

ZGC满足了如下三大目标:

停顿时间控制在10ms之内
停顿时间不会因为堆变大而变长
堆大小支持TB级

尽管ZGC在对象回收的吞吐量方面略逊于G1回收器(差距小于15%),但综合来讲,ZGC已经是目前足够好用的垃圾回收器了。

可令人遗憾的是,ZGC这么好的垃圾回收器,暂时并不支持ARM架构处理器。(ZGC处于实验阶段)

为此,Bisheng JDK团队对OpenJDK进行了扩展,使得ARM架构处理器也能享受到ZGC带来的垃圾回收优化。

目前,该优化针对的版本是Bisheng JDK 11。


Bishengjdk8:
https://gitee.com/openeuler/bishengjdk-8

Bishengjdk11:
https://gitee.com/openeuler/bishengjdk-11


此外,大家也可以关注一下12月的openEuler Summit 2020大会,点击下面图片即可访问:

内容来自用户分享和网络整理,不保证内容的准确性,如有侵权内容,可联系管理员处理 点击这里给我发消息
标签: