英文原文：Java 10 - The Story So Far

　　從 Java 9 發(fā)布到現在已經過去兩個月了，根據最新的發(fā)布計劃，距離下一個 Java 版本發(fā)布只有四個月時間。Java 10 的新特性還在確認當中，所以從現在到 GA 版中間還是有可能加入重大的變更。不管怎樣，在這四個月里，開發(fā)者還是可以期待一些新的特性能夠被添加到 Java 10 中。

　　新的特性和增強一般通過 Java Enhancement Process（JEP）或 Java Community Process 標準請求（JSR）進行跟蹤。因為 Java 10 的時間線較短，范圍也相對較小，所以 Java 10 的變更將通過 JEP 進行跟蹤。

　　有望被包含在 Java 10 中的特性是那些已經處于 Targeted 或 Proposed 狀態(tài)的 JEP，它們包括：

• 286：本地變量類型推斷
• 296：統(tǒng)一 JDK 倉庫
• 304：垃圾回收器接口
• 307：G1 的并行 Full GC
• 310：應用程序類數據共享
• 312：ThreadLocal 握手機制

　　JEP 296 是一次純粹的清理工作，而 JEP 304 加強了不同垃圾回收器的代碼隔離，并為垃圾回收器引入更簡潔的接口。

　　JEP 304 意味著廠商可以更自由地選擇特定的 GC 算法來構建 JDK，因為現在有多種處于開發(fā)當中的 GC，如 Shenandoah、ZGC 和 Epsilon，在未來可以使用這些 GC 算法。社區(qū)也在努力棄用甚至移除 Concurrent Mark Sweep（CMS）垃圾回收器，只是目前還沒有可用的替代品。

　　比較有意思的變更或許是 JEP 286，增強的本地變量類型推斷可以讓開發(fā)者免去很多變量申明模板代碼。也就是說，在下一個版本中，下面的變量聲明是合法的：

var list = new ArrayList<String>();  // infers ArrayList<String>var stream = list.stream ();          // infers Stream<String>

　　這種語法只限于初始化過的本地變量和 for 循環(huán)中的本地變量。

　　它其實是個語法糖，在語義上并沒有任何變化。不過，該特性有可能在 Java 開發(fā)者當中引起熱議。

　　其他三個變更都將在性能方面帶來一些影響。

　　JEP 307 解決了 G1 垃圾回收器的一個問題——截止到 Java 9，G1 的 Full GC 采用的是單線程算法。也就是說，G1 在發(fā)生 Full GC 時會嚴重影響性能。JEP 307 的目的就是要采用并行 GC 算法，在發(fā)生 Full GC 時可以使用多個線程進行并行回收。

　　JEP 310 對類數據共享（CDS）進行了擴展，JVM 可以將一些類記錄到一個共享的壓縮文件里，在 JVM 下一次啟動時可以將這個文件映射到 JVM 進程，以此來減少啟動時間。該文件也可以在多個 JVM 間共享，在同一個機器上運行多個 JVM 時，這樣做可以減少內存占用。

　　該功能在 Java 5 中就已存在，但截止到 Java 9，該功能只允許 bootstrap 類加載器加載壓縮的類。JEP 310 的目的是擴展該功能，讓應用程序和自定義類加載器也能加載壓縮的類。該特性目前僅在 Oracle JDK 中可用，OpenJDK 并不包含該特性。

　　JEP 計劃將該特性從 Oracle 私有倉庫中遷移到公共倉庫，從 Java 10 往后，常規(guī)版本（非 LTS）將會使用 OpenJDK 的二進制包。此舉表明有用戶正在使用該特性，所以需要在 OpenJDK 中也支持該特性。

　　JEP 312 旨在改進虛擬機性能，在應用程序線程上調用回調不再需要執(zhí)行全局虛擬機安全點操作，這意味著 JVM 可以停止單個線程。一些底層小改進包括：

• 降低堆棧跟蹤取樣所帶來的影響（如進行 profiling）。
• 減少信號依賴以獲得更好的堆棧取樣。
• 通過停止單獨線程改進偏向鎖。
• 從 JVM 移除了一些內存屏障。

　　從整體來看，Java 10 似乎并沒有包含重大新特性或性能改進。這是可以理解的，畢竟這是新發(fā)布周期下的第一個版本。