Java 10 新特性有哪些呢

這期內(nèi)容當(dāng)中小編將會(huì)給大家?guī)碛嘘P(guān)Java 10 新特性有哪些呢，文章內(nèi)容豐富且以專業(yè)的角度為大家分析和敘述，閱讀完這篇文章希望大家可以有所收獲。

局部變量類型推斷

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

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

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

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

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

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

在運(yùn)算符允許在沒有綁定 ArrayList <> 的類型的情況下初始化列表的寫法為：

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

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

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

整合 JDK 代碼倉庫

為了簡(jiǎn)化開發(fā)流程，Java 10 中會(huì)將多個(gè)代碼庫合并到一個(gè)代碼倉庫中。

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

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

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

統(tǒng)一的垃圾回收接口

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

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

并行全垃圾回收器 G1

大家如果接觸過 Java 性能調(diào)優(yōu)工作，應(yīng)該會(huì)知道，調(diào)優(yōu)的最終目標(biāo)是通過參數(shù)設(shè)置來達(dá)到快速、低延時(shí)的內(nèi)存垃圾回收以提高應(yīng)用吞吐量，盡可能的避免因內(nèi)存回收不及時(shí)而觸發(fā)的完整        GC（Full GC 會(huì)帶來應(yīng)用出現(xiàn)卡頓）。

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

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

應(yīng)用程序類數(shù)據(jù)共享

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

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

其原理為：在啟動(dòng)時(shí)記錄加載類的過程，寫入到文本文件中，再次啟動(dòng)時(shí)直接讀取此啟動(dòng)文本并加載。設(shè)想如果應(yīng)用環(huán)境沒有大的變化，啟動(dòng)速度就會(huì)得到提升。

可以想像為類似于操作系統(tǒng)的休眠過程，合上電腦時(shí)把當(dāng)前應(yīng)用環(huán)境寫入磁盤，再次使用時(shí)就可以快速恢復(fù)環(huán)境。

對(duì)大型企業(yè)應(yīng)用程序的內(nèi)存使用情況的分析表明，此類應(yīng)用程序通常會(huì)將數(shù)以萬計(jì)的類加載到應(yīng)用程序類加載器中，如果能夠?qū)?AppCDS 應(yīng)用于這些應(yīng)用，將為每個(gè) JVM        進(jìn)程節(jié)省數(shù)十乃至數(shù)百兆字節(jié)的內(nèi)存。另外對(duì)于云平臺(tái)上的微服務(wù)分析表明，許多服務(wù)器在啟動(dòng)時(shí)會(huì)加載數(shù)千個(gè)應(yīng)用程序類，AppCDS 可以讓這些服務(wù)快速啟動(dòng)并改善整個(gè)系統(tǒng)響應(yīng)時(shí)間。

線程-局部管控

在已有的 Java 版本中，JVM 線程只能全部啟用或者停止，沒法做到對(duì)單獨(dú)某個(gè)線程的操作。為了能夠?qū)为?dú)的某個(gè)線程進(jìn)行操作，Java 10 中線程管控引入 JVM        安全點(diǎn)的概念，將允許在不運(yùn)行全局 JVM 安全點(diǎn)的情況下實(shí)現(xiàn)線程回調(diào)，由線程本身或者 JVM        線程來執(zhí)行，同時(shí)保持線程處于阻塞狀態(tài)，這種方式使得停止單個(gè)線程變成可能，而不是只能啟用或停止所有線程。通過這種方式顯著地提高了現(xiàn)有 JVM 功能的性能開銷，并且改變了到達(dá) JVM        全局安全點(diǎn)的現(xiàn)有時(shí)間語義。

增加的參數(shù)為：-XX:ThreadLocalHandshakes (默認(rèn)為開啟)，將允許用戶在支持的平臺(tái)上選擇安全點(diǎn)。

自 Java 9 以來便開始了一些對(duì) JDK 的調(diào)整，用戶每次調(diào)用 javah 工具時(shí)會(huì)被警告該工具在未來的版本中將會(huì)執(zhí)行的刪除操作。當(dāng)編譯 JNI 代碼時(shí)，已不再需要單獨(dú)的        Native-Header 工具來生成頭文件，因?yàn)檫@可以通過 Java 8（JDK-7150368）中添加的 javac 來完成。在未來的某一時(shí)刻，JNI        將會(huì)被 Panama 項(xiàng)目的結(jié)果取代，但是何時(shí)發(fā)生還沒有具體時(shí)間表。

額外的 Unicode 語言標(biāo)簽擴(kuò)展

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

表 1.Unicode 擴(kuò)展表

如 Java 10 加入的一個(gè)方法：

清單 4. Unicode        語言標(biāo)簽擴(kuò)展示例

通過這個(gè)方法，可以采用某種數(shù)字樣式，區(qū)域定義或者時(shí)區(qū)來獲得時(shí)間信息所需的語言地域本地環(huán)境信息。

備用存儲(chǔ)裝置上的堆分配

硬件技術(shù)在持續(xù)進(jìn)化，現(xiàn)在可以使用與傳統(tǒng) DRAM 具有相同接口和類似性能特點(diǎn)的非易失性 RAM。Java 10 中將使得 JVM        能夠使用適用于不同類型的存儲(chǔ)機(jī)制的堆，在可選內(nèi)存設(shè)備上進(jìn)行堆內(nèi)存分配。

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

要在這樣的備用設(shè)備上進(jìn)行堆分配，可以使用堆分配參數(shù) -XX：AllocateHeapAt =        <path>，這個(gè)參數(shù)將指向文件系統(tǒng)的文件并使用內(nèi)存映射來達(dá)到在備用存儲(chǔ)設(shè)備上進(jìn)行堆分配的預(yù)期結(jié)果。

基于 Java 的 實(shí)驗(yàn)性 JIT        編譯器

Java 10 中開啟了基于 Java 的 JIT 編譯器 Graal，并將其用作 Linux/x64 平臺(tái)上的實(shí)驗(yàn)性 JIT 編譯器開始進(jìn)行測(cè)試和調(diào)試工作，另外 Graal 將使用        Java 9 中引入的 JVM 編譯器接口（JVMCI）。

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

Java 10 中默認(rèn)情況下 HotSpot 仍使用的是 C2 編譯器，要啟用 Graal 作為 JIT 編譯器，請(qǐng)?jiān)?Java 命令行上使用以下參數(shù)：

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

根證書認(rèn)證

自 Java 9 起在 keytool 中加入?yún)?shù) -cacerts，可以查看當(dāng)前 JDK 管理的根證書。而 Java 9 中          cacerts 目錄為空，這樣就會(huì)給開發(fā)者帶來很多不便。從 Java 10 開始，將會(huì)在 JDK 中提供一套默認(rèn)的 CA 根證書。

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

基于時(shí)間的版本發(fā)布模式

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

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

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

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

當(dāng)時(shí)，Mark 也提出來一種基于時(shí)間命名版本號(hào)的機(jī)制，比如下一個(gè)將于 2018 年 3 月發(fā)布的版本，就是 18.3，再下一個(gè)版本是 18.9，以后版本依此類推。

不過經(jīng)過討論，考慮和之前版本號(hào)的兼容等問題，最終選擇的命名機(jī)制是：

$FEATURE.$INTERIM.$UPDATE.$PATCH

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

$INTERIM，中間版本號(hào)，在大版本中間發(fā)布的，包含問題修復(fù)和增強(qiáng)的版本，不會(huì)引入非兼容性修改。

上述就是小編為大家分享的Java 10 新特性有哪些呢了，如果剛好有類似的疑惑，不妨參照上述分析進(jìn)行理解。如果想知道更多相關(guān)知識(shí)，歡迎關(guān)注億速云行業(yè)資訊頻道。