漫画：毕昇 JDK，重现了“活字印刷术”的传奇作者|小灰来源|程序员小灰（

文章插图
作者 | 小灰
来源 | 程序员小灰（ID：chengxuyuanxiaohui）
文章插图
文章插图
文章插图
文章插图
文章插图
文章插图
文章插图
中央处理器，即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的时候，进行类加载工作会占用一定的时间。
【漫画：毕昇 JDK，重现了“活字印刷术”的传奇】如果我们同时运行多个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满足了如下三大目标：