Java 12版本完整指南新功能 | Henn Idan

Shenandoah：一個低暫停時間的垃圾收集器

這個實驗性功能想要新增一個名為Shenandoah的新垃圾收集（GC）演算法，該演算法適用於喜歡響應性和可預測的短暫停頓的應用程式。
此功能引入了一種演算法，該演算法足夠高效，允許程式在可用記憶體中執行，但也經過最佳化，永遠不會中斷正在執行的程式超過幾毫秒。
Shenandoah演算法將透過與正在執行的Java執行緒同時進行疏散工作來幫助減少GC暫停時間。它交換併發CPU週期和空間以改善暫停時間，並且暫停時間與堆大小無關，這意味著無論堆是200 MB還是200 GB，您都將具有相同的一致暫停時間。
Oracle確實注意到這不是解決所有JVM暫停問題，因為這些問題可能是由於安全時間點（TTSP）問題引起的，甚至是監控應用程式的膨脹。對於這些情況，演算法就不太有關了。

切換表示式

這個JEP旨在擴充套件switch語句; 一個多路分支語句，它提供了一種簡單的方法，可以根據表示式的值將執行分配到程式碼內的不同部分。
這種擴充套件目前處於預覽模式，使我們能夠將switch用作語句或表示式，以簡化編碼併為另一個即將到來的JEP做準備，例如，模式匹配（305）。
為了理解它的含義，Oracle分享了以下示例。下面一段是舊程式碼，不必要的冗長和視覺上嘈雜的程式碼經常掩蓋難以除錯的錯誤，其中缺少break語句表明發生意外中斷：

switch (day) {
    case MONDAY:
    case FRIDAY:
    case SUNDAY:
        System.out.println(6);
        break;
    case TUESDAY:
        System.out.println(7);
        break;
    case THURSDAY:
    case SATURDAY:
        System.out.println(8);
        break;
    case WEDNESDAY:
        System.out.println(9);
        break;
}

switch (day) {
    case MONDAY, FRIDAY, SUNDAY -> System.out.println(6);
    case TUESDAY                -> System.out.println(7);
    case THURSDAY, SATURDAY     -> System.out.println(8);
    case WEDNESDAY              -> System.out.println(9);
}

G1改進
Java 12附帶了2個預設垃圾收集器G1的更新。第一個標題為“ G1的Abortable Mixed Collections ”有助於使G1混合收集在可能超過暫停目標時中止。
目前，G1使用分析引擎來選擇在收集期間要完成的工作量，並且一旦確定了收集並且已經開始收集，則G1必須收集所有區域中的所有沒有停止的活動物件，這導致垃圾收集器超過暫停時間目標，這是JEP旨在解決的問題。
另一個G1功能還專注於提高垃圾收集器的效能，特別是返回未使用的已提交記憶體。
當前版本的G1僅在完整GC或併發週期內從Java堆返回記憶體。由於G1努力完全避免完整的GC，並且只觸發基於Java堆佔用和分配活動的併發週期，因此在許多情況下它不會返回Java堆記憶體，除非在外部強制執行此操作。
這就是“ 迅速從G1返回未使用的提交記憶體 ”，專注於透過在G1空閒時自動將Java堆記憶體返回到作業系統來增強垃圾收集器。

Java 12中引入的其他功能包括：

• Microbenchmark Suite - 為JDK原始碼新增基本的微基準測試套件，使開發人員可以輕鬆執行現有的微基準測試並建立新的基準測試。
• JVM常量API - 引入API以模擬關鍵類檔案和執行時工件的名義描述，例如可從常量池載入的常量。此API對於操作Java類和方法的工具非常有用。
• 預設CDS存檔 - 增強JDK構建過程以生成類資料共享（CDS）存檔並改進開箱即用的啟動時間。

這些值得麼？
隨著不斷的更新，我們看到越來越多的功能引入到該語言中 - 但是開發人員對這一最近的變化有何看法？在大型系統和企業中升級和實現新的語言功能並不總是那麼容易，更不用說建立與遺留程式碼的相容性以及團隊所做的本地技巧和駭客攻擊。
事實上，當我們冷酷地看待最近的Java版本時，我們發現頻繁釋出並不意味著最新版本是最受歡迎的版本。透過檢視Google趨勢，我們可以看到並非如此。
儘管Java 8是系列中“最古老”的成員，但它的普及程度是不可否認的。Java 11正在獲得一些牽引力，可能是因為它是最新的長期支援版本，而Java 12則位於列表的最底層。這是一個新版本，所以我們願意給它一些時間，但從目前的狀態來看，它似乎不會改變太多。
這是否意味著甲骨文應該停止六個月的節奏？好吧，不。這一決定是為了讓Oracle能夠比以前更快地釋出“更小”的功能，從而幫助Java與市場上的其他語言保持一致。
如果你問我們，這個改變只會幫助Java保持其功能和受歡迎程度，無論是對於年輕人和即將到來的開發人員以及程式設計領域的資深人士。現在我們唯一的問題是...... Java 13將會介紹什麼，以及這些功能將如何改變我們的編碼方式？