共計 6396 個字符，預計需要花費 16 分鐘才能閱讀完成。

這期內容當中丸趣 TV 小編將會給大家帶來有關 Java 10 新特性有哪些呢，文章內容豐富且以專業的角度為大家分析和敘述，閱讀完這篇文章希望大家可以有所收獲。

局部變量類型推斷

局部變量類型推斷是 Java 10 中最值得開發人員注意的新特性，這是 Java 語言開發人員為了簡化 Java 應用程序的編寫而進行的又一重要改進。

這一新功能將為 Java 增加一些新語法，允許開發人員省略通常不必要的局部變量類型初始化聲明。新的語法將減少 Java         代碼的冗長度，同時保持對靜態類型安全性的承諾。局部變量類型推斷主要是向 Java 語法中引入在其他語言（比如 C#、JavaScript）中很常見的保留類型名稱          var。但需要特別注意的是：var         不是一個關鍵字，而是一個保留字。只要編譯器可以推斷此種類型，開發人員不再需要專門聲明一個局部變量的類型，也就是可以隨意定義變量而不必指定變量的類型。這種改進對于鏈式表達式來說，也會很方便。以下是一個簡單的例子：

清單 1.         局部變量類型推斷示例

1

2

var list = new ArrayList String // ArrayList String

var stream = list.stream(); // Stream String

看著是不是有點 JS 的感覺？有沒有感覺越來越像 JS 了？雖然變量類型的推斷在 Java 中不是一個嶄新的概念，但在局部變量中確是很大的一個改進。說到變量類型推斷，從 Java 5         中引進泛型，到 Java 7 的 操作符允許不綁定類型而初始化 List，再到 Java 8 中的 Lambda 表達式，再到現在 Java        10 中引入的局部變量類型推斷，Java 類型推斷正大刀闊斧地向前進步、發展。

而上面這段例子，在以前版本的 Java 語法中初始化列表的寫法為：

清單 2. Java         類型初始化示例

1

2

List String list = new ArrayList String

Stream String stream = getStream();

在運算符允許在沒有綁定 ArrayList 的類型的情況下初始化列表的寫法為：

清單 3. Java 7         之后版本類型初始化示例

1

2

List String list = new LinkedList ();

Stream String stream = getStream();

但這種 var 變量類型推斷的使用也有局限性，僅局限于具有初始化器的局部變量、增強型 for 循環中的索引變量以及在傳統 for         循環中聲明的局部變量，而不能用于推斷方法的參數類型，不能用于構造函數參數類型推斷，不能用于推斷方法返回類型，也不能用于字段類型推斷，同時還不能用于捕獲表達式（或任何其他類型的變量聲明）。

不過對于開發者而言，變量類型顯式聲明會提供更加全面的程序語言信息，對于理解和維護代碼有很大的幫助。Java 10         中新引入的局部變量類型推斷能夠幫助我們快速編寫更加簡潔的代碼，但是局部變量類型推斷的保留字 var 的使用勢必會引起變量類型可視化缺失，并不是任何時候使用        var 都能容易、清晰的分辨出變量的類型。一旦 var 被廣泛運用，開發者在沒有 IDE         的支持下閱讀代碼，勢必會對理解程序的執行流程帶來一定的困難。所以還是建議盡量顯式定義變量類型，在保持代碼簡潔的同時，也需要兼顧程序的易讀性、可維護性。

整合 JDK 代碼倉庫

為了簡化開發流程，Java 10 中會將多個代碼庫合并到一個代碼倉庫中。

在已發布的 Java 版本中，JDK 的整套代碼根據不同功能已被分別存儲在多個 Mercurial 存儲庫，這八個 Mercurial         存儲庫分別是：root、corba、hotspot、jaxp、jaxws、jdk、langtools、nashorn。

雖然以上八個存儲庫之間相互獨立以保持各組件代碼清晰分離，但同時管理這些存儲庫存在許多缺點，并且無法進行相關聯源代碼的管理操作。其中最重要的一點是，涉及多個存儲庫的變更集無法進行原子提交        （atomic commit）。例如，如果一個 bug         修復時需要對獨立存儲兩個不同代碼庫的代碼進行更改，那么必須創建兩個提交：每個存儲庫中各一個。這種不連續性很容易降低項目和源代碼管理工具的可跟蹤性和加大復雜性。特別是，不可能跨越相互依賴的變更集的存儲庫執行原子提交這種多次跨倉庫的變化是常見現象。

為了解決這個問題，JDK 10 中將所有現有存儲庫合并到一個 Mercurial 存儲庫中。這種合并的一個次生效應是，單一的 Mercurial         存儲庫比現有的八個存儲庫要更容易地被鏡像 (作為一個 Git         存儲庫)，并且使得跨越相互依賴的變更集的存儲庫運行原子提交成為可能，從而簡化開發和管理過程。雖然在整合過程中，外部開發人員有一些阻力，但是 JDK 開發團隊已經使這一更改成為 JDK        10 的一部分。

統一的垃圾回收接口

在當前的 Java 結構中，組成垃圾回收器（GC）實現的組件分散在代碼庫的各個部分。盡管這些慣例對于使用 GC 計劃的 JDK         開發者來說比較熟悉，但對新的開發人員來說，對于在哪里查找特定 GC 的源代碼，或者實現一個新的垃圾收集器常常會感到困惑。更重要的是，隨著 Java modules         的出現，我們希望在構建過程中排除不需要的 GC，但是當前 GC 接口的橫向結構會給排除、定位問題帶來困難。

為解決此問題，需要整合并清理 GC 接口，以便更容易地實現新的 GC，并更好地維護現有的 GC。Java 10 中，hotspot/gc 代碼實現方面，引入一個干凈的 GC         接口，改進不同 GC 源代碼的隔離性，多個 GC 之間共享的實現細節代碼應該存在于輔助類中。這種方式提供了足夠的靈活性來實現全新 GC         接口，同時允許以混合搭配方式重復使用現有代碼，并且能夠保持代碼更加干凈、整潔，便于排查收集器問題。

并行全垃圾回收器 G1

大家如果接觸過 Java 性能調優工作，應該會知道，調優的最終目標是通過參數設置來達到快速、低延時的內存垃圾回收以提高應用吞吐量，盡可能的避免因內存回收不及時而觸發的完整        GC（Full GC 會帶來應用出現卡頓）。

G1 垃圾回收器是 Java 9 中 Hotspot 的默認垃圾回收器，是以一種低延時的垃圾回收器來設計的，旨在避免進行 Full        GC，但是當并發收集無法快速回收內存時，會觸發垃圾回收器回退進行 Full GC。之前 Java 版本中的 G1 垃圾回收器執行 GC         時采用的是基于單線程標記掃描壓縮算法（mark-sweep-compact）。為了最大限度地減少 Full GC 造成的應用停頓的影響，Java 10 中將為 G1 引入多線程并行        GC，同時會使用與年輕代回收和混合回收相同的并行工作線程數量，從而減少了 Full GC 的發生，以帶來更好的性能提升、更大的吞吐量。

Java 10 中將采用并行化 mark-sweep-compact 算法，并使用與年輕代回收和混合回收相同數量的線程。具體并行 GC           線程數量可以通過：-XX：ParallelGCThreads 參數來調節，但這也會影響用于年輕代和混合收集的工作線程數。

應用程序類數據共享

在 Java 5 中就已經引入了類數據共享機制 (Class Data Sharing，簡稱 CDS)，允許將一組類預處理為共享歸檔文件，以便在運行時能夠進行內存映射以減少 Java         程序的啟動時間，當多個 Java 虛擬機（JVM）共享相同的歸檔文件時，還可以減少動態內存的占用量，同時減少多個虛擬機在同一個物理或虛擬的機器上運行時的資源占用。簡單來說，Java         安裝程序會把 rt.jar 中的核心類提前轉化成內部表示，轉儲到一個共享存檔（shared archive）中。多個 Java 進程（或者說 JVM         實例）可以共享這部分數據。為改善啟動和占用空間，Java 10 在現有的 CDS 功能基礎上再次拓展，以允許應用類放置在共享存檔中。

CDS 特性在原來的 bootstrap 類基礎之上，擴展加入了應用類的 CDS (Application Class-Data Sharing) 支持。

其原理為：在啟動時記錄加載類的過程，寫入到文本文件中，再次啟動時直接讀取此啟動文本并加載。設想如果應用環境沒有大的變化，啟動速度就會得到提升。

可以想像為類似于操作系統的休眠過程，合上電腦時把當前應用環境寫入磁盤，再次使用時就可以快速恢復環境。

對大型企業應用程序的內存使用情況的分析表明，此類應用程序通常會將數以萬計的類加載到應用程序類加載器中，如果能夠將 AppCDS 應用于這些應用，將為每個 JVM         進程節省數十乃至數百兆字節的內存。另外對于云平臺上的微服務分析表明，許多服務器在啟動時會加載數千個應用程序類，AppCDS 可以讓這些服務快速啟動并改善整個系統響應時間。

線程 - 局部管控

在已有的 Java 版本中，JVM 線程只能全部啟用或者停止，沒法做到對單獨某個線程的操作。為了能夠對單獨的某個線程進行操作，Java 10 中線程管控引入 JVM         安全點的概念，將允許在不運行全局 JVM 安全點的情況下實現線程回調，由線程本身或者 JVM         線程來執行，同時保持線程處于阻塞狀態，這種方式使得停止單個線程變成可能，而不是只能啟用或停止所有線程。通過這種方式顯著地提高了現有 JVM 功能的性能開銷，并且改變了到達 JVM         全局安全點的現有時間語義。

增加的參數為：-XX:ThreadLocalHandshakes (默認為開啟)，將允許用戶在支持的平臺上選擇安全點。

自 Java 9 以來便開始了一些對 JDK 的調整，用戶每次調用 javah 工具時會被警告該工具在未來的版本中將會執行的刪除操作。當編譯 JNI 代碼時，已不再需要單獨的        Native-Header 工具來生成頭文件，因為這可以通過 Java 8（JDK-7150368）中添加的 javac 來完成。在未來的某一時刻，JNI         將會被 Panama 項目的結果取代，但是何時發生還沒有具體時間表。

額外的 Unicode 語言標簽擴展

自 Java 7 開始支持 BCP 47 語言標記以來，JDK 中便增加了與日歷和數字相關的 Unicode 區域設置擴展，在 Java 9 中，新增支持 ca 和 nu         兩種語言標簽擴展。而在 Java 10 中將繼續增加 Unicode 語言標簽擴展，具體為：增強 java.util.Locale 類及其相關的        API，以更方便的獲得所需要的語言地域環境信息。同時在這次升級中還帶來了如下擴展支持：

表 1.Unicode 擴展表

如 Java 10 加入的一個方法：

清單 4. Unicode         語言標簽擴展示例

1

java.time.format.DateTimeFormatter::localizedBy

通過這個方法，可以采用某種數字樣式，區域定義或者時區來獲得時間信息所需的語言地域本地環境信息。

備用存儲裝置上的堆分配

硬件技術在持續進化，現在可以使用與傳統 DRAM 具有相同接口和類似性能特點的非易失性 RAM。Java 10 中將使得 JVM         能夠使用適用于不同類型的存儲機制的堆，在可選內存設備上進行堆內存分配。

一些操作系統中已經通過文件系統提供了使用非 DRAM 內存的方法。例如：NTFS DAX 模式和 ext4        DAX。這些文件系統中的內存映射文件可繞過頁面緩存并提供虛擬內存與設備物理內存的相互映射。與 DRAM 相比，NV-DIMM 可能具有更高的訪問延遲，低優先級進程可以為堆使用        NV-DIMM 內存，允許高優先級進程使用更多 DRAM。

要在這樣的備用設備上進行堆分配，可以使用堆分配參數 -XX：AllocateHeapAt =         path，這個參數將指向文件系統的文件并使用內存映射來達到在備用存儲設備上進行堆分配的預期結果。

基于 Java 的 實驗性 JIT         編譯器

Java 10 中開啟了基于 Java 的 JIT 編譯器 Graal，并將其用作 Linux/x64 平臺上的實驗性 JIT 編譯器開始進行測試和調試工作，另外 Graal 將使用        Java 9 中引入的 JVM 編譯器接口（JVMCI）。

Graal 是一個以 Java 為主要編程語言、面向 Java bytecode 的編譯器。與用 C++ 實現的 C1 及 C2 相比，它的模塊化更加明顯，也更加容易維護。Graal         既可以作為動態編譯器，在運行時編譯熱點方法；亦可以作為靜態編譯器，實現 AOT 編譯。在 Java 10 中，Graal 作為試驗性 JIT 編譯器一同發布（JEP 317）。將        Graal 編譯器研究項目引入到 Java 中，或許能夠為 JVM 性能與當前 C++ 所寫版本匹敵（或有幸超越）提供基礎。

Java 10 中默認情況下 HotSpot 仍使用的是 C2 編譯器，要啟用 Graal 作為 JIT 編譯器，請在 Java 命令行上使用以下參數：

清單 5. 啟用 Graal 為 JIT         編譯器示例

1

-XX：+ UnlockExperimentalVMOptions -XX：+ UseJVMCICompiler

根證書認證

自 Java 9 起在 keytool 中加入參數 -cacerts，可以查看當前 JDK 管理的根證書。而 Java 9 中          cacerts 目錄為空，這樣就會給開發者帶來很多不便。從 Java 10 開始，將會在 JDK 中提供一套默認的 CA 根證書。

作為 JDK 一部分的 cacerts 密鑰庫旨在包含一組能夠用于在各種安全協議的證書鏈中建立信任的根證書。但是，JDK 源代碼中的          cacerts 密鑰庫至目前為止一直是空的。因此，在 JDK 構建中，默認情況下，關鍵安全組件（如        TLS）是不起作用的。要解決此問題，用戶必須使用一組根證書配置和 cacerts 密鑰庫下的 CA 根證書。

基于時間的版本發布模式

雖然 JEP        223 中引入的版本字符串方案較以往有了顯著的改進。但是，該方案并不適合以后嚴格按照六個月的節奏來發布 Java 新版本的這種情況。

按照 JEP 223 的語義中，每個基于 JDK 構建或使用組件的開發者（包括 JDK         的發布者）都必須提前敲定版本號，然后切換過去。開發人員則必須在代碼中修改檢查版本號的相關代碼，這對所有參與者來說都很尷尬和混亂。

Java 10 中將重新編寫之前 JDK 版本中引入的版本號方案，將使用基于時間模型定義的版本號格式來定義新版本。保留與 JEP 223         版本字符串方案的兼容性，同時也允許除當前模型以外的基于時間的發布模型。使開發人員或終端用戶能夠輕松找出版本的發布時間，以便開發人員能夠判斷是否將其升級到具有最新安全修補程序或可能的附加功能的新版本。

Oracle Java 平臺組的首席架構師 Mark Reinhold 在博客上介紹了有關 Java 未來版本的一些想法（你能接受 Java 9 的下一個版本是 Java 18.3         嗎？）。他提到，Java 計劃按照時間來發布，每半年一個版本，而不是像之前那樣按照重要特性來確定大版本，如果某個大的特性因故延期，這個版本可能一拖再拖。

當時，Mark 也提出來一種基于時間命名版本號的機制，比如下一個將于 2018 年 3 月發布的版本，就是 18.3，再下一個版本是 18.9，以后版本依此類推。

不過經過討論，考慮和之前版本號的兼容等問題，最終選擇的命名機制是：

$FEATURE.$INTERIM.$UPDATE.$PATCH

$FEATURE，每次版本發布加 1，不考慮具體的版本內容。2018 年 3 月的版本是 JDK 10，9 月的版本是 JDK 11，依此類推。

$INTERIM，中間版本號，在大版本中間發布的，包含問題修復和增強的版本，不會引入非兼容性修改。

上述就是丸趣 TV 小編為大家分享的 Java 10 新特性有哪些呢了，如果剛好有類似的疑惑，不妨參照上述分析進行理解。如果想知道更多相關知識，歡迎關注丸趣 TV 行業資訊頻道。