你想了解的JDK 10版本更新都在這裡

2020 年 8 月 21 日
筆記
MoreThanJava

「MoreThanJava」 宣揚的是 「學習，不止 CODE」，本系列 Java 基礎教程是自己在結合各方面的知識之後，對 Java 基礎的一個總回顧，旨在 「幫助新朋友快速高質量的學習」。
當然 不論新老朋友 我相信您都可以 從中獲益。如果覺得 「不錯」 的朋友，歡迎 「關注 + 留言 + 分享」，文末有完整的獲取鏈接，您的支持是我前進的最大的動力！

特性總覽

以下是 Java 10 中的引入的部分新特性。關於 Java 10 新特性更詳細的介紹可參考這裡。

基於時間的發行版本控制（JEP 322）
局部變量類型推斷（JEP 286）
試驗性 JIT 編譯器（JEP 317）
應用程序類數據共享（JEP 310）
用於 G1 的並行 Full GC（JEP 307）
清理垃圾收集器接口（JEP 304）
其他 Unicode 語言標籤擴展（JEP 314）
根證書（JEP 319）
線程本地握手（JEP 312）
備用存儲設備上的堆分配（JEP 316）
刪除本機頭生成工具——javah（JEP 313）
將JDK森林合併到單個存儲庫中（JEP 296）
API 變更

一. 基於時間的發行版本控制（JEP 322）

發行版本號的前世今生

自 Java 江山易主，JDK 發行版本的字符串命名方式一直是一個耐人尋味的話題。

單就下載 JDK 時，所看到的簡短版本字符串形式來說，在 7u40 版本之前，u 之後的數字，代表了 JDK 發佈以來的第幾個修正版本，然而 Oracle 改變規則，為了彰顯出安全之類的重大 修補（Cirtical Patch Updates）版本，採用奇數命名，而 Bug 修復、API 修改之類的 維護版本，則採用偶數。（另有版本號 $MAJOR.$MINOR.$SECURITY 的格式來區分 Bug 修正和 API 修改）

為此，之前既有的 JDK 6/7 發佈版本，還被重新命名。（下方演示）

   Actual                    Hypothetical
Release Type           long               short
------------           ------------------------ 
Security 2013/06       1.7.0_25-b15       7u25
Minor    2013/09       1.7.0_40-b43       7u40
Security 2013/10       1.7.0_45-b18       7u45
Security 2014/01       1.7.0_51-b13       7u51
Minor    2014/05       1.7.0_60-b19       7u60

就結論而言，重新命名之後，從 7u9、6u37 開始，就可以從奇偶數來判別是否為重大修補版本；至於 7u40 之後的版本，重大修補版本 是基於 5 的倍數，遇偶數加一，而 維護版本 則會是 20 的倍數。如此（不直觀）的命名方式，被規範在了 JEP223 中。（隨着 JDK 9 一起發佈的）

然而，自 JDK 8 發佈之後，Oracle 的 Java 架構師 Mark Reinhold 就希望，未來 Java 發佈可以基於時間，以半年為周期，持續發佈新版本，讓一些有用的小特性，也能被開發者使用，因此，JEP 223 的規範就不再適用了，而在 JDK 9 發佈後，他們針對新版本曾經提出過基於 $YEAR.$MONTH 格式，然而收到了社區極大的反對，為此，還提出了三個替代方案，收集各方的意見。（//goo.gl/7CA8B3)

那麼，Java 下一個特性版本是 8.3？1803？還是 10？調查結果顯示，社群大多數都支持 10，Stephen Colebourne 也發出請求（//goo.gl/i5J44T），並表示 Java 不像 Ubuntu 這類操作系統，基於 $YEAR.$MONTH 並不合適。

最終，Oracle 採用了 $FEATURE.$INTERIM.$UPDATE.$PATCH 這樣的方案，並規定在了 JEP 322 中。

JEP 322 新模式解讀

通過採用基於時間的發行周期，Oracle 更改了 Java SE 平台和 JDK 的版本字符串方案以及相關的版本信息，以適用於當前和將來的基於時間的發行模型。

版本號的新模式是：

$FEATURE.$INTERIM.$UPDATE.$PATCH

$ FEATURE：計數器將每 6 個月遞增一次，並基於功能發佈版本，例如：JDK 10，JDK 11。
$ INTERIM：對於包含兼容錯誤修復和增強功能但沒有不兼容更改的非功能版本，計數器將增加。通常，這將是零，因為六個月內不會有任何臨時發佈。這保留了對發佈模型的將來修訂。
$ UPDATE：計數器將增加，用於解決安全問題，回歸和較新功能中的錯誤的兼容更新版本。此功能會在功能發佈後一個月更新，此後每三個月更新一次。2018 年 4 月版本是 JDK 10.0.1，7 月版本是 JDK 10.0.2，依此類推
$ PATCH：計數器將增加以用於緊急釋放以解決嚴重問題。

並添加了新的 API 以通過編程的方式獲取這些計數器：

Version version = Runtime.version();
version.feature();
version.interim();
version.update();
version.patch();

現在，讓我們來看一下返回版本信息的 Java 啟動器：

$ java -version
java version "10" 2018-03-20
Java(TM) SE Runtime Environment 18.3 (build 10+46)
Java HotSpot(TM) 64-Bit Server VM 18.3 (build 10+46, mixed mode)

版本號格式為 10，因為沒有其他計數器為零。發佈日期已添加。可以將 18.3 理解為 Year 2018＆3rd Month，版本 10 + 46 是版本 10 的 46 版本。對於 JDK 10.0.1 的假設版本 93，版本將為 10.0.1 + 93。

因此，對於 Java 9 來說，目前可以看到的版本，會是 9.0.4 這樣的格式，至於 2018 年 3 月發佈的特性版本為 10，到了 9 月提供的新版本，就是 11，JDK 11 預計會是長期支援版本，所以，在版本字串上，也會特別顯示 LTS（long-term support）。

二. 局部變量類型推斷（JEP 286）

概述

JDK 10 中最明顯的增強功能之一是使用初始化程序對局部變量進行類型推斷。

在 Java 9 之前，我們必須明確寫出局部變量的類型，並確保它與用於初始化它的初始化程序兼容：

String message = "Good bye, Java 9";

在 Java 10 中，這是我們可以聲明局部變量的方式：

@Test
public void whenVarInitWithString_thenGetStringTypeVar() {
    var message = "Hello, Java 10";
    assertTrue(message instanceof String);
}

我們沒有提供 message 的具體類型，相反，我們把 message 標記為了 var，編譯器將從右側的初始化程序的類型推斷出 message 的類型。（上面的例子中 message 為 String 類型）

請注意，此功能僅適用於帶有初始化程序的局部變量。它不能用於成員變量、方法參數、返回類型等——初始化程序是必須的，否則，編譯器無法推斷出其類型。

這個功能有助於我們減少樣板式的代碼，例如：

Map<Integer, String> map = new HashMap<>();

現在可以改寫為：

var idToNameMap = new HashMap<Integer, String>();

這也有助於我們把重點放在變量名，而不是變量類型上。

要注意的另一件事是 var 不是關鍵字——這確保了使用 var 作為函數或變量名的程序的向後兼容性。var 是一個保留類型名，就像 int 一樣。

最後，使用 var 不會增加運行時的開銷，也不會使 Java 稱為動態類型的語言。變量的類型仍然是在編譯時進行判斷，以後也無法更改。

非法使用 var 的情況解析

1、如果沒有初始化程序，var 將無法工作：

var n; // error: cannot use 'var' on variable without initializer

2、如果將其初始化為 null，也不會起作用：

var emptyList = null; // error: variable initializer is 'null'

3、不適用於非局部變量：

public var word = "hello"; // error: 'var' is not allowed here

4、Lambda 表達式需要顯式的類型，因此無法使用 var：

var p = (String s) -> s.length() > 10; // error: lambda expression needs an explicit target-type

5、數組初始化程序也不支持：

var arr = { 1, 2, 3 }; // error: array initializer needs an explicit target-type

使用 var 的準則

在某些情況下，我們可以合法使用 var，但這樣做並不是一個好主意。

例如，在代碼的可讀性降低的情況下：

var result = obj.prcoess();

在這裡，儘管可以合法使用 var，但很難理解 process() 返回的類型，從而讓代碼的可讀性降低。

java.net(OpenJDK 官網)上專門有一篇文章介紹了 Java 中的局部變量類型推斷的書寫準則，該文章討論了在使用此功能時應該注意的姿勢和如何使用的一些良好建議。

另外，最好避免使用 var 的另一種情況是在流水線較長的流中：

var x = emp.getProjects.stream()
  .findFirst()
  .map(String::length)
  .orElse(0);

另外，將 var 與不可引用類型一起使用可能會導致意外錯誤。

比如，如果我們將 var 與匿名類實例一起使用：

@Test
public void whenVarInitWithAnonymous_thenGetAnonymousType() {
    var obj = new Object() {};
    assertFalse(obj.getClass().equals(Object.class));
}

現在，如果我們嘗試將另一個 Object 分配給 obj，則會出現編譯錯誤：

obj = new Object(); // error: Object cannot be converted to <anonymous Object>

這是因為 obj 的推斷類型不是 Object。

三. 試驗性 JIT 編譯器（JEP 317）

Graal 是用Java編寫的，與 HotSpot JVM 集成的動態編譯器。它專註於高性能和可擴展性。它也是 JDK 9 中引入的實驗性 Ahead-of-Time（AOT）編譯器的基礎。

JDK 10 使 Graal 編譯器可以用作 Linux / x64 平台上的實驗性 JIT 編譯器。

要將 Graal 用作 JIT 編譯器，請在 Java 命令行上使用以下選項：

-XX:+UnlockExperimentalVMOptions -XX:+UseJVMCICompiler

請注意，這是一個實驗性功能，我們不一定會獲得比現有JIT編譯器更好的性能。

想要了解更多內容的童鞋請參考 Chris Seaton 的演講：//chrisseaton.com/truffleruby/jokerconf17/

（ps：長文 + 特別底層警告..）

四. 應用程序類數據共享(JEP 310)

JDK 5 中引入的類數據共享允許將一組類預處理成共享的歸檔文件，然後在運行時對其進行內存映射，以減少啟動時間，這還可以在多個 JVM 共享相同的歸檔文件時減少動態內存佔用。

CDS 只允許引導類裝入器，將該特性限制為系統類。應用程序 CDS (AppCDS）擴展了 CDS 以允許內置的系統類裝入器。內置的平台類裝入器和用於裝入歸檔類的自定義類裝入器。這使得對應用程序類使用該特性成為可能。

我們可以使用以下步驟來使用這個功能：

1、獲取要存檔的類列表

以下命令會將HelloWorld 應用程序加載的類轉儲到hello.lst中：

$ java -Xshare:off -XX:+UseAppCDS -XX:DumpLoadedClassList=hello.lst \ 
    -cp hello.jar HelloWorld

2、創建 AppCDS 存檔

以下命令使用hello.lst 作為輸入創建hello.js a ：

$ java -Xshare:dump -XX:+UseAppCDS -XX:SharedClassListFile=hello.lst \
    -XX:SharedArchiveFile=hello.jsa -cp hello.jar

3、使用 AppCDS 存檔

以下命令以hello.jsa 作為輸入啟動HelloWorld 應用程序：

$ java -Xshare:on -XX:+UseAppCDS -XX:SharedArchiveFile=hello.jsa \
    -cp hello.jar HelloWorld

AppCDS 是用於 JDK 8 和 JDK 9 的 Oracle JDK 中的一項商業功能。現在它是開源的，並且可以公開使用。

五. 用於 G1 的並行 Full GC(JEP 307)

G1 垃圾收集器是自 JDK 9 以來的默認垃圾收集器。但是，G1 的 Full GC 使用了單線程的 mark-sweep-compact 算法。

它已 更改為 Java 10 中 的並行mark-sweep-compact算法 ，有效地減少了 Full GC 期間的停滯時間。

六. 清理垃圾收集器接口（JEP 304）

這個 JEP 是未來的變化。通過引入公共垃圾收集器接口，它改善了不同垃圾收集器的代碼隔離。

次更改為內部 GC 代碼提供了更好的模塊化。將來將有助於在不更改現有代碼庫的情況下添加新 GC，還有助於刪除或保留以前的 GC。

官方的動機解釋： （傳送門）

當前，每個垃圾收集器實現都由其 src/hotspot/share/gc/$NAME 目錄內的源文件組成，例如 G1 在中 src/hotspot/share/gc/g1，CMS 在 src/hotspot/share/gc/cms 等中。但是，在 HotSpot 中散布着一些零散的信息。例如，大多數 GC 需要某些障礙，這些障礙需要在運行時，解釋器 C1 和 C2 中實現。這些障礙並不包含在 GC 的具體目錄，但在共享解釋器，而不是實施，C1 和 C2 的源代碼（通常由長守衛if– else–chains）。同樣的問題也適用於診斷代碼，例如 MemoryMXBeans。此源代碼布局有幾個缺點：

對於GC開發人員，實施新的垃圾收集器需要有關所有這些地方的知識，以及如何擴展它們以滿足其特定需求的知識。

對於不是 GC 開發人員的 HotSpot 開發人員，在哪裡為給定 GC 找到特定的代碼段會造成混亂。

在構建時很難排除特定的垃圾收集器。該#define INCLUD E_ALL_GCS長期以來建立與唯一內置串行收集JVM的一種方式，但這種機制變得過於呆板。

較乾淨的 GC 接口將使實現新的收集器更加容易，使代碼更加清潔，並且在構建時排除一個或多個收集器也更加容易。添加一個新的垃圾收集器應該是實現一組有據可查的接口，而不是弄清 HotSpot 中所有需要更改的地方。

七. 其他Unicode語言標籤擴展（JEP 314）

此功能增強了 java.util.Locale 和相關 API，以實現 BCP 47 語言標籤的其他 Unicode 擴展。從 Java SE 9 開始，受支持的 BCP 47 U 語言擴展名是 “ca” 和 “nu”。該 JEP 將增加對以下附加擴展的支持：

cu（貨幣類型）
fw（一周的第一天）
rg（區域覆蓋）
tz（時區）

為了支持這些附加擴展，對以下各種 API 進行了更改以提供基於 U 或附加擴展的信息：

java.text.DateFormat::get*Instance
java.text.DateFormatSymbols::getInstance
java.text.DecimalFormatSymbols::getInstance
java.text.NumberFormat::get*Instance
java.time.format.DateTimeFormatter::localizedBy
java.time.format.DateTimeFormatterBuilder::getLocalizedDateTimePattern
java.time.format.DecimalStyle::of
java.time.temporal.WeekFields::of
java.util.Calendar::{getFirstDayOfWeek,getMinimalDaysInWeek}
java.util.Currency::getInstance
java.util.Locale::getDisplayName
java.util.spi.LocaleNameProvider

八. 根證書（JEP 319）

cacerts 密鑰庫（迄今為止到目前為止是空的）旨在包含一組根證書，這些根證書可用於建立對各種安全協議所使用的證書鏈的信任。

結果，在 OpenJDK 構建中，諸如 TLS 之類的關鍵安全組件默認情況下不起作用。

藉助 Java 10，Oracle 將 Oracle Java SE Root CA 程序中 的根證書開源了 ，以使 OpenJDK 構建對開發人員更具吸引力，並減少了這些構建與 Oracle JDK 構建之間的差異。

九. 線程本地握手（JEP 312）

這是用於提高 JVM 性能的內部特性。

握手操作是在線程處於安全點狀態時為每個 JavaThread 執行的回調。回調由線程本身或 VM 線程執行，同時保持線程處於阻塞狀態。

這個特性提供了一種無需執行全局 VM 安全點即可在線程上執行回調的方法。使停止單個線程，而不是停止所有線程或不停止線程成為可能，而且代價低廉。

十. 備用存儲設備上的堆分配(JEP 316)

應用程序的內存消耗越來越大，本地雲應用程序、內存中的數據庫、流應用程序都在增加。為了滿足這些服務，有各種可用的內存架構。這個特性增強了 HotSpot VM 在用戶指定的備用內存設備(比如NV-DIMM)上分配 Java 對象堆的能力。

這個 JEP 的目標是具有與 DRAM 相同語義(包括原子操作的語義)的可選內存設備，因此，可以在不更改現有應用程序代碼的情況下，將其用於對象堆，而不是用於 DRAM。

十一. 刪除本機頭生成工具—javah (JEP 313)

這是一個從 JDK 中刪除 javah 工具的常規更改。工具功能是作為 JDK 8 的一部分在 javac 中添加的，它提供了在編譯時編寫使 javah 無用的本機頭文件的能力。

十二. 將JDK森林合併到單個存儲庫中(JEP 296)

多年來，有各種各樣的 Mercurial 存儲庫用於 JDK 代碼基。不同的存儲庫確實提供了一些優勢，但它們也有各種操作上的缺點。作為這個變化的一部分，JDK 森林的許多存儲庫被合併到一個存儲庫中，以簡化和簡化開發。

十三. API 變更

Java 10 添加和刪除了 API。Java 9 引入了增強的棄用，其中某些 API 被標記為將在未來的版本中刪除。

於是這些 API 被刪除了：你可以在這裡找到被刪除的 API。

新增API: Java 10 中新增 73 個API。您可以在這裡找到添加的 API 並進行比較。

讓我們來看看對我們直接有用的部分。

不可修改集合的改進

Java 10 中有一些與不可修改集合相關的更改

copyOf()

java.util.List、java.util.Map 和 java.util.Set 都有了一個新的靜態方法 copyOf(Collection)。

它返回給定 Collection 的不可修改的副本：

jshell> var originList = new ArrayList<String>();
originList ==> []

jshell> originList.add("歡迎關注公眾號：");
$2 ==> true

jshell> originList.add("我沒有三顆心臟");
$3 ==> true

jshell> var copyList = List.copyOf(originList)
copyList ==> [歡迎關注公眾號：, 我沒有三顆心臟]

jshell> originList.add("獲取更多精彩內容")
$5 ==> true

jshell> System.out.println(copyList)
[歡迎關注公眾號：, 我沒有三顆心臟]

jshell> copyList.add("獲取更多精彩內容")
|  異常錯誤 java.lang.UnsupportedOperationException
|        at ImmutableCollections.uoe (ImmutableCollections.java:73)
|        at ImmutableCollections$AbstractImmutableCollection.add (ImmutableCollections.java:77)
|        at (#7:1)

jshell>

toUnmodifiable()

java.util.Collectors 獲得其他方法來將 Stream 收集到不可修改的 List、Map 或 Set 中：

@Test(expected = UnsupportedOperationException.class)
public void whenModifyToUnmodifiableList_thenThrowsException() {
    List<Integer> evenList = someIntList.stream()
      .filter(i -> i % 2 == 0)
      .collect(Collectors.toUnmodifiableList());
    evenList.add(4);
}

任何嘗試修改此類集合的嘗試都會導致 java.lang.UnsupportedOperationException 運行時異常。

Optinal 新增方法 orElseThrow()

java.util.Optional，java.util.OptionalDouble，java.util.OptionalInt 和 java.util.OptionalLong 都有一個新方法 orElseThrow()，它不接受任何參數，如果不存在任何值，則拋出 NoSuchElementException：

@Test
public void whenListContainsInteger_OrElseThrowReturnsInteger() {
    Integer firstEven = someIntList.stream()
      .filter(i -> i % 2 == 0)
      .findFirst()
      .orElseThrow();
    is(firstEven).equals(Integer.valueOf(2));
}

它與現有的 get() 方法同義，並且現在是它的首選替代方法。

參考資料

OpenJDK 官方說明 – //openjdk.java.net/projects/jdk/10/
Java 10 Features | JournalDev – //www.journaldev.com/20395/java-10-features
想跳舞的 Java | 林信良 – //www.ithome.com.tw/voice/122249
Java 10 Performance Improvements | Baeldung – //www.baeldung.com/java-10-performance-improvements

文章推薦

這都JDK15了，JDK7還不了解？ – //www.wmyskxz.com/2020/08/18/java7-ban-ben-te-xing-xiang-jie/
全網最通透的 Java 8 版本特性講解 – //www.wmyskxz.com/2020/08/19/java8-ban-ben-te-xing-xiang-jie/
Java9的這些史詩級更新你都不知道？ – //www.wmyskxz.com/2020/08/20/java9-ban-ben-te-xing-xiang-jie/
「MoreThanJava」系列文集 – //www.wmyskxz.com/categories/MoreThanJava/

本文已收錄至我的 Github 程序員成長系列 【More Than Java】，學習，不止 Code，歡迎 star：//github.com/wmyskxz/MoreThanJava

個人公眾號 ：wmyskxz，個人獨立域名博客：wmyskxz.com，堅持原創輸出，下方掃碼關注，2020，與您共同成長！

非常感謝各位人才能 看到這裡，如果覺得本篇文章寫得不錯，覺得 「我沒有三顆心臟」有點東西 的話，求點贊，求關注，求分享，求留言！

創作不易，各位的支持和認可，就是我創作的最大動力，我們下篇文章見！

Tags: MoreThanJava

你想了解的JDK 10版本更新都在這裡

特性總覽

一. 基於時間的發行版本控制（JEP 322）

發行版本號的前世今生

JEP 322 新模式解讀

二. 局部變量類型推斷（JEP 286）

概述

非法使用 var 的情況解析

使用 var 的準則

三. 試驗性 JIT 編譯器（JEP 317）

四. 應用程序類數據共享(JEP 310)

五. 用於 G1 的並行 Full GC(JEP 307)

六. 清理垃圾收集器接口（JEP 304）

七. 其他Unicode語言標籤擴展（JEP 314）

八. 根證書（JEP 319）

九. 線程本地握手（JEP 312）

十. 備用存儲設備上的堆分配(JEP 316)

十一. 刪除本機頭生成工具—javah (JEP 313)

十二. 將JDK森林合併到單個存儲庫中(JEP 296)

十三. API 變更

不可修改集合的改進

copyOf()

toUnmodifiable()

Optinal 新增方法 orElseThrow()

參考資料

文章推薦

VirMach 便宜 VPS

QNews

你想了解的JDK 10版本更新都在這裡

特性總覽

一. 基於時間的發行版本控制（JEP 322）

發行版本號的前世今生

JEP 322 新模式解讀

二. 局部變量類型推斷（JEP 286）

概述

非法使用 var 的情況解析

使用 var 的準則

三. 試驗性 JIT 編譯器（JEP 317）

四. 應用程序類數據共享(JEP 310)

五. 用於 G1 的並行 Full GC(JEP 307)

六. 清理垃圾收集器接口（JEP 304）

七. 其他Unicode語言標籤擴展（JEP 314）

八. 根證書（JEP 319）

九. 線程本地握手（JEP 312）

十. 備用存儲設備上的堆分配(JEP 316)

十一. 刪除本機頭生成工具—javah (JEP 313)

十二. 將JDK森林合併到單個存儲庫中(JEP 296)

十三. API 變更

不可修改集合的改進

copyOf()

toUnmodifiable()

Optinal 新增方法 orElseThrow()

參考資料

文章推薦

分享此文：

Related Posts

three.js 着色器材質之紋理

疫情下的在家辦公

面經手冊 · 第6篇《帶着面試題學習紅黑樹操作原理，解析什麼時候染色、怎麼進行旋轉、與2-3樹有什麼關聯》

Docker 架構及工作原理

VirMach 便宜 VPS

QNews

熱門文章

熱門搜尋