中央處理器，即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大會，點擊下面圖片即可訪問：
轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/214196.html
標籤：python