如何評價 Java11？
JDK11作為LTS長期支援版本, 在今後幾年會逐步像JDK8一樣流行, 因為下一個LTS版本要等待3年後的JDK17了.
從JDK11累積了JDK9,10帶來的大量特性(以下特性評論包括了9和10的特性), 不過對很多初級開發者而言, 語法層面改進的並不多, 這也是Java一貫的保守風格(非貶義).
最大的變化是JDK9就加入的模組化, 同時也繼續向前相容非模組化的工程.
語法層面最大的改進是加入了大多語言都有的"var", 而且還很保守地沒加入"val".
這個版本是Java有史以來最大的一次瘦身, 移除了Demos and Samples,移除了不常用的GC搭配,移除了jhat和javah,移除了JavaEE和JavaFX(體積不小,還自帶瀏覽器核心),移除了VisualVM和MissionControl(都是不小的),移除了Derby資料庫. 當然這些都是因為放到現代已經沒什麼用了,有更好的替代品,或獨立出去了(同時也為了更快的更新迭代).
瘦身後的安裝包體積較JDK9/10大幅縮減, 甚至比JDK8還小了.
現在也不再單獨發JRE, Server JRE這些小體積版本, 從安裝後的檔案中可以看到傳統分離的JRE和JDK現在已經合併了, Java的編譯部分已經可以看成是執行時的一部分了.
現在也不再推出32位版本, 當然是基於32位市場目前已經很小的形勢下, 想繼續用32位JDK只能用JDK8了. 另外ARM平臺的JDK貌似不公開發布了.
以上的版本合併和精簡瘦身後, Oracle的JDK和OpenJDK的差別更小, 之間的可替代性也更好.
GC方面, G1已成預設(確實對大部分應用來說均衡性最好,也不用多考慮手動調節), G1較JDK8有一些改進,不是很大,繼續用JDK8也不用太在意. 更多人關注的是新出的ZGC, 首先要提示這目前只是試驗品,別輕易在生產用途中使用(想想JDK6時敢不敢用G1).
ZGC的優點主要是停頓極短到幾乎可以無視的程度, 而且跟堆的規模關係不大, 因此最適合用在對停頓及其敏感和超大堆的場合.
再說說目前ZGC的缺點, GC效能(吞吐量)偏低, 尤其是堆較小的情況, 我個人評測的結果是CMS是1倍時間的話, G1是1.1倍時間, ZGC是1.6倍左右的時間(根據堆大小和分配速度不同有較大的浮動,大致在1.2到1.8倍之間); 不支援分代(新生代垃圾較多的情況優勢不大); 不支援壓縮指標(因為需要用到指標的一些位,不過對較大的堆來說不算問題了)
GC這塊沒有銀彈, ZGC有優點就會有相應的缺點, 不停頓的代價就是把停頓需要做的事分擔到引用(指標)的讀寫上了, 雖然每次讀寫只多了幾個指令, 但大量讀寫就把效能問題凸顯了.
我個人建議是ZGC只用在對停頓要求極端苛刻的情況和堆特別大的(>32G). 除此以外, <=512M的堆仍然建議用ParrellelGC, 512M~4G用CMS(可惜估計後續版本要移除了), 4G~32G用G1.
AOT方面也有不少支援, 不過對伺服器開發來說意義不大, AOT的優化能力理論上不會超越JIT. AOT的好處只是啟動快, 對於頻繁啟動的短生命期程式來說有些用(如shell那些命令); 另外AOT也會顯著加大反編譯的難度, 這個只對客戶端執行閉源應用,或者交付給只有使用權的客戶有用.
最後再說說模組化, 習慣了之前JDK開發的人來說, 現階段體會不到模組化有多大用, 要說減小體積,JRE本身的大小在現代的應用來說也不算什麼.
安裝目錄多了個jmods目錄, 包含了70多M的jmod壓縮包, 佔了JDK安裝包的接近一半的體積了, jmod檔案本質上就是把JRE做了裁剪分割(有些模組感覺分的太細了),其中主要是可執行程式和class檔案. 最基本的jmod就是java.base.jmod, 包含了JVM的核心.
如果JDK安裝包移除了jmods, 也移除了40多M的原始碼壓縮包, 就不到50M了, 用7z可以壓到30多M, 包括完整的JRE(含編譯功能), 可以說相當瘦身了(java.base.jmod也有十多M).
另外, 細心的人會發現之前的rt.jar和tools.jar已經不存在了, 換成了modules和ct.sym檔案, 估計是優化整合的class檔案結構, 可以載入得更快吧(同時也利於壓縮).
至於licence問題, 絕大部分普通的開發者都沒必要擔心, 大不了轉成OpenJDK也不麻煩. 只要別像Google那樣對Java/JVM本身做魔改就行. Oracle提供的安裝包還是很方便的.
歡迎Java工程師朋友們加入Java進階高階架構群：855355016
本群提供免費的學習指導 架構資料 以及解答
不懂得問題都可以在本群提出來 之後還會有職業生涯規劃以及面試指導