毕昇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

标签：Java,JDK,回收,架构,重现,JVM,活字印刷术,ZGC
来源： https://blog.51cto.com/u_15127650/2782303