标签：方案 bootstra 问题 幸好 基本 ofo cat 垃圾回收 x86
毕昇JDK，重现了 “活字印刷术” 的传奇
中央处理器，即CPU，包含很多种设计架构。其中最常见的架构有两种，一种是X86架构，一种是ARM架构。
这两种架构有什么不同呢？主要是使用的指令集不一样。
X86架构使用CISC指令集，即复杂指令集，最典型的代表就是英特尔处理器。
ARM架构使用RISC指令集，即精简指令集，华为的鲲鹏就是基于ARM架构。
OpenJDK，对于X86架构处理器有很好的支持，虽然也基本支持ARM架构处理器，但是在性能上并不理想。
正是为了弥补OpenJDK在ARM架构上运行的劣势，华为开源了自己研发的JDK发行版，并贡献到openEuler 开源社区，这就是咱们提到的Bisheng JDK。
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。
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大会，点击下面图片即可访问：
标签：方案 bootstra 问题 幸好 基本 ofo cat 垃圾回收 x86
原文地址：https://blog.51cto.com/14982143/2548887
