畢昇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大會，點選下面圖片即可存取：