知識星球導讀：JDK11將在今年年內釋出，其中會引入新的GC演演算法ZGC。ZGC標的包括，能夠處理TB級別的HEAP GC，GC停頓時間不超過10ms，相比G1，吞吐減少不超過15%，十分值得關註，本文是對ZGC的簡單介紹。
JDK 11釋出的日子臨近了，最近一個讓人欣喜的訊息就是，JDK 11中將會加入實驗性質的ZGC，相關JEP見：[1]
我們知道，ZGC專案需要完成的標的是：控制Java的垃圾回收時長在10ms以內，絕對不超過10ms，並且使用了該垃圾回收策略之後，吞吐對比當前Java預設的垃圾回收策略G1，下降不超過15%
所謂實驗性質是指該策略在JDK 11中只會支援Linux，其他平臺暫不支援，還有Graal等也需要等後續版本才會支援
首先我們來瞭解一下G1，G1是新一代Java的垃圾回收策略，據快手大佬說，自從用了G1，他們的JVM就不再tune了，從一個側面說明瞭G1垃圾回收策略的能耐，但是對於一些延遲敏感的場景，G1還是有些不太能滿足需求，比如常見的遊戲，尤其是實時類的網遊
那ZGC出現後就針對該問題予以最佳化，那最佳化到什麼程度呢？JEP 333的wiki上給出了第一份benchmark，不得不說，這一份benchmark的表現讓人驚嘆，牛逼得不要不要的，牛逼到什麼程度呢？來看資料：
128G記憶體
ZGC
avg: 1.091ms (+/-0.215ms)
95th percentile: 1.380ms
99th percentile: 1.512ms
99.9th percentile: 1.663ms
99.99th percentile: 1.681ms
max: 1.681msG1
avg: 156.806ms (+/-71.126ms)
95th percentile: 316.672ms
99th percentile: 428.095ms
99.9th percentile: 543.846ms
99.99th percentile: 543.846ms
max: 543.846ms
平均gc時長在1.091毫秒，方差為0.215毫秒，最長gc時長是1.681毫秒，不到2毫秒，就算是2毫秒吧，這意味著什麼呢？
意味著，幾乎所有的民用場合，都可以用java來寫了，而且隨心所欲滴造物件，想弄多少個就弄多少個，老一點的Java使用者都知道，早期的Java程式碼書寫的時候，會建議使用者用什麼StringBuffer而不是用+來連線String，因為String是immutable的，所以用+的話，會有大量臨時的String物件出現，導致string pool暴漲，增加gc的壓力
但是如果一個full gc，才不到2毫秒的話，你就是拼命造物件，又怎麼樣呢？一個人要窮到什麼程度的人，才會去在意這區區2毫秒的暫停呢？這就猶如2018年了，還在跟深圳路邊的小攤小販討價還價2分錢一樣，毫無意義，更不要說Java的編譯的時候，會自動將一些常見的+最佳化成StringBuffer
解決了這個問題之後，這也為下一步fp程式設計應用開啟了大門，我們都知道，fp語言特別喜歡用immutable，以前immutable用多了，效能就下來了，這也是為什麼lisp早期無法跟c競爭的原因，效能上達不到，但是如果是2ms的gc停頓的話，那效能上的差異就非常小了，幾乎可以忽略不計，那lisp等fp語言在演演算法表達上的優勢就會體現出來，所以ZGC對於fp語言生態來說，意義也十分重大，fp大規模應用的基礎已經初具雛形了
當然要想利用上JVM，我們還需要一個能夠連線起不同語言和JVM的一個利器，那這個就是Graalvm[2]，也就是Openjdk的一個外掛，有了Graal之後，就能夠將Lisp，Haskell等fp語言執行在JVM上，並且可以透過aot，jlink等技術，將其打包成size很小的可執行檔案，併發布出去，但是目前Graal還處於研發階段，還沒正式release，雖然也快了，但是第一版重點是支援JS/Node，Ruby，Python(scipy)和R這幾個語言；學術氣息比較重的Lisp還有Haskell的支援還需要等社群貢獻或者後續開發。
參考文獻：
[1] http://openjdk.java.net/jeps/333
[2] https://www.graalvm.org
[3] https://wiki.openjdk.java.net/display/zgc/Main
[4] http://jdk.java.net/zgc/
相關閱讀：
高可用架構
改變網際網路的構建方式
長按二維碼 關註「高可用架構」公眾號
