JDK14都要問世了，你還在用JDK8嗎

2020-02-22 22:55 作者:小明哥會(huì)飛 0人讀過 | 我要投稿

?作者：楊小羊2333
出處：https://www.cnblogs.com/yn869251541/ ?

? ?Java開發(fā)工具包（JDK）14已進(jìn)入發(fā)布候選階段，總體功能基本已確定。計(jì)劃中的標(biāo)準(zhǔn)Java升級(jí)將具有新功能，例如JDK Flight Recorder事件流，模式匹配和開關(guān)表達(dá)式。JDK 14計(jì)劃在Java設(shè)定六個(gè)月的發(fā)布節(jié)奏之后，于2020年3月17 日正式發(fā)布。

針對(duì)JDK 14的功能包括：

JFR事件流提供一個(gè)API，用于持續(xù)使用來自流程內(nèi)和流程外應(yīng)用程序的JFR數(shù)據(jù)。JFR是用于收集有關(guān)正在運(yùn)行的Java應(yīng)用程序的概要分析和診斷數(shù)據(jù)的工具。事件流建議記錄與非流情況相同的事件集，并且如果可能，開銷小于百分之一。事件流必須與基于磁盤和基于內(nèi)存的非流記錄共存。在這種情況下，HotSpot VM使用JFR發(fā)出500個(gè)以上的數(shù)據(jù)點(diǎn)，而其中的大多數(shù)數(shù)據(jù)僅可通過分析日志文件來使用，因此很容易激發(fā)這種提議。當(dāng)前，用戶必須開始錄制，停止錄制，將內(nèi)容轉(zhuǎn)儲(chǔ)到磁盤，然后解析錄制文件。這對(duì)于應(yīng)用程序概要分析非常有效，但不適用于監(jiān)視目的。監(jiān)控使用情況的一個(gè)示例是顯示動(dòng)態(tài)更新數(shù)據(jù)的儀表板。創(chuàng)建記錄會(huì)產(chǎn)生開銷，例如將數(shù)據(jù)從磁盤存儲(chǔ)庫(kù)復(fù)制到單獨(dú)的記錄文件。如果有一種方法可以在不創(chuàng)建新記錄文件的情況下從磁盤存儲(chǔ)庫(kù)讀取正在記錄的數(shù)據(jù)，則可以避免很多開銷。
計(jì)劃進(jìn)行的改進(jìn) NullPointerExceptions涉及通過準(zhǔn)確描述哪個(gè)變量為null來提高JVM生成的異常的可用性。該提案的作者希望為開發(fā)人員和支持人員提供有關(guān)程序過早終止的有用信息，并通過更清楚地將動(dòng)態(tài)異常與靜態(tài)程序代碼相關(guān)聯(lián)來提高對(duì)程序的理解。一個(gè)目標(biāo)是減少開發(fā)人員的困惑和擔(dān)憂NullPointerExceptions。
非易失性映射的字節(jié)緩沖區(qū)將添加新的特定于JDK的文件映射模式，該模式允許使用FileChannel API創(chuàng)建MappedByteBuffer引用非易失性內(nèi)存（NVM）的實(shí)例。NVM使程序員可以跨程序運(yùn)行來構(gòu)建和更新程序狀態(tài)，而不會(huì)產(chǎn)生輸入和輸出操作通常需要的大量復(fù)制或翻譯成本。這對(duì)于交易程序尤其重要。因此，此JDK增強(qiáng)建議的主要目標(biāo)是確?？蛻舳丝梢赃B貫且有效地從Java程序訪問和更新NVM。第二個(gè)目標(biāo)是使用在class中定義的受限制的JDK內(nèi)部API來實(shí)現(xiàn)此提交行為Unsafe，因此除其他類外，它可以重用它。MappedByteBuffer可能需要提交給NVM。另一個(gè)目標(biāo)是允許現(xiàn)有API跟蹤在NVM上映射的緩沖區(qū)，以進(jìn)行監(jiān)視和管理。目標(biāo)OS / CPU平臺(tái)包括Linux / x64和Linux / AArch64。
開關(guān)表達(dá)式通過擴(kuò)展switch使其可以用作語(yǔ)句或表達(dá)式而簡(jiǎn)化了編碼。在JDK 12和JDK 13中都進(jìn)行預(yù)覽之后，開關(guān)表達(dá)式有望成為JDK 14的永久功能。開關(guān)表達(dá)式還為使用模式匹配做好了準(zhǔn)備switch。模式匹配使開發(fā)人員可以更簡(jiǎn)潔，安全地從對(duì)象中有條件地提取組件。
G1垃圾回收器的NUMA感知內(nèi)存分配，旨在提高大型計(jì)算機(jī)上的G1性能。
刪除并發(fā)標(biāo)記掃描（CMS）垃圾收集器，該垃圾收集器先前已棄用并計(jì)劃刪除。CMS的后繼者包括ZGC和Shenandoah。
將ZGC移植到MacOS。到目前為止，僅Linux才支持它。
刪除java.util.jar軟件包中的pack200和unpack200工具以及Pack200 API 。所有這些在Java SE 11中已棄用，目的是將來刪除它們。Pack200是JAR文件的壓縮方案。
記錄，它將提供一種緊湊的語(yǔ)法來聲明為淺層不可變數(shù)據(jù)的透明持有者的類。該提案指出，聲明淺不可改變的，行為良好的名義數(shù)據(jù)集合應(yīng)該簡(jiǎn)單明了。
一種打包工具，處于開發(fā)的孵化階段，用于打包自包含的Java應(yīng)用程序。該工具將基于JavaFX javapackager。此類工具已包含在Java中，但作為刪除JavaFX的一部分從JDK 11中刪除。
通過為操作員提供模式匹配來增強(qiáng)語(yǔ)言instanceof。這將是JDK 14中的預(yù)覽功能。模式匹配可以更簡(jiǎn)潔和安全地表示程序中的通用邏輯，主要是從對(duì)象中有條件地提取組件。
文本塊的第二個(gè)預(yù)覽，這是一種多行字符串文字，它避免了大多數(shù)轉(zhuǎn)義序列的需要，并以可預(yù)測(cè)的方式自動(dòng)格式化字符串。文本塊將在需要時(shí)使開發(fā)人員可以控制格式，簡(jiǎn)化Java程序的編寫，并增強(qiáng)字符串的可讀性。文本塊在JDK 13中進(jìn)行了預(yù)覽；JDK 14迭代將添加轉(zhuǎn)義序列以管理顯式空白和換行控制。
不贊成使用Parallel Scavenge和Serial Old垃圾收集算法的組合。Java維護(hù)者認(rèn)為這種組合很少使用，但需要大量維護(hù)。
將ZGC（Z垃圾收集器）移植到Windows。在恢復(fù)到提議的目標(biāo)列表之后，此功能再次移至正式目標(biāo)列表。
外部存儲(chǔ)器訪問API，引入了Java程序的API，可以安全有效地訪問Java堆外部的外部存儲(chǔ)器。該API應(yīng)該可以替代Java程序訪問內(nèi)存（包括nio.ByteBuffer和）的主要途徑sun.misc.Unsafe。新的API應(yīng)該能夠在各種類型的內(nèi)存上運(yùn)行，包括本機(jī)，持久性內(nèi)存和托管堆。API不可能破壞JVM的安全性。內(nèi)存釋放應(yīng)在源代碼中明確。該API有望幫助開發(fā)本機(jī)互操作支持，這是巴拿馬項(xiàng)目的目標(biāo)。
棄用Solaris / Sparc，Solaris / x64和Linux / Sparc端口，以在將來的發(fā)行版中將其刪除。放棄對(duì)這些端口的支持將使OpenJDK貢獻(xiàn)者能夠加速新功能的開發(fā)。盡管Solaris和Sparc是Java最初的創(chuàng)建者Sun Microsystems的關(guān)鍵技術(shù)，但近年來，它們已被Linux OS和Intel處理器取代了其技術(shù)領(lǐng)域。