這期內(nèi)容當(dāng)中小編將會(huì)給大家?guī)碛嘘P(guān)Java 10 新特性有哪些呢,文章內(nèi)容豐富且以專業(yè)的角度為大家分析和敘述,閱讀完這篇文章希望大家可以有所收獲。
站在用戶的角度思考問題,與客戶深入溝通,找到舟山網(wǎng)站設(shè)計(jì)與舟山網(wǎng)站推廣的解決方案,憑借多年的經(jīng)驗(yàn),讓設(shè)計(jì)與互聯(lián)網(wǎng)技術(shù)結(jié)合,創(chuàng)造個(gè)性化、用戶體驗(yàn)好的作品,建站類型包括:網(wǎng)站制作、成都做網(wǎng)站、企業(yè)官網(wǎng)、英文網(wǎng)站、手機(jī)端網(wǎng)站、網(wǎng)站推廣、域名與空間、虛擬空間、企業(yè)郵箱。業(yè)務(wù)覆蓋舟山地區(qū)。
局部變量類型推斷是 Java 10 中最值得開發(fā)人員注意的新特性,這是 Java 語言開發(fā)人員為了簡化 Java 應(yīng)用程序的編寫而進(jìn)行的又一重要改進(jìn)。
這一新功能將為 Java 增加一些新語法,允許開發(fā)人員省略通常不必要的局部變量類型初始化聲明。新的語法將減少 Java 代碼的冗長度,同時(shí)保持對(duì)靜態(tài)類型安全性的承諾。局部變量類型推斷主要是向 Java 語法中引入在其他語言(比如 C#、JavaScript)中很常見的保留類型名稱 var
。但需要特別注意的是:var
不是一個(gè)關(guān)鍵字,而是一個(gè)保留字。只要編譯器可以推斷此種類型,開發(fā)人員不再需要專門聲明一個(gè)局部變量的類型,也就是可以隨意定義變量而不必指定變量的類型。這種改進(jìn)對(duì)于鏈?zhǔn)奖磉_(dá)式來說,也會(huì)很方便。以下是一個(gè)簡單的例子:
1 2 |
|
看著是不是有點(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 語法中初始化列表的寫法為:
1 2 |
|
在運(yùn)算符允許在沒有綁定 ArrayList <>
的類型的情況下初始化列表的寫法為:
1 2 |
|
但這種 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 中新引入的局部變量類型推斷能夠幫助我們快速編寫更加簡潔的代碼,但是局部變量類型推斷的保留字 var
的使用勢(shì)必會(huì)引起變量類型可視化缺失,并不是任何時(shí)候使用 var 都能容易、清晰的分辨出變量的類型。一旦 var
被廣泛運(yùn)用,開發(fā)者在沒有 IDE 的支持下閱讀代碼,勢(shì)必會(huì)對(duì)理解程序的執(zhí)行流程帶來一定的困難。所以還是建議盡量顯式定義變量類型,在保持代碼簡潔的同時(shí),也需要兼顧程序的易讀性、可維護(hù)性。
為了簡化開發(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)行原子提交成為可能,從而簡化開發(fā)和管理過程。雖然在整合過程中,外部開發(fā)人員有一些阻力,但是 JDK 開發(fā)團(tuán)隊(duì)已經(jīng)使這一更改成為 JDK 10 的一部分。
在當(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)有代碼,并且能夠保持代碼更加干凈、整潔,便于排查收集器問題。
大家如果接觸過 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ù)。
在 Java 5 中就已經(jīng)引入了類數(shù)據(jù)共享機(jī)制 (Class Data Sharing,簡稱 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í)的資源占用。簡單來說,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í)間表。
自 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ò)展支持:
如 Java 10 加入的一個(gè)方法:
1 |
|
通過這個(gè)方法,可以采用某種數(shù)字樣式,區(qū)域定義或者時(shí)區(qū)來獲得時(shí)間信息所需的語言地域本地環(huán)境信息。
硬件技術(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 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ù):
1 |
|
自 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 根證書。
雖然 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)注創(chuàng)新互聯(lián)行業(yè)資訊頻道。
本文名稱:Java10新特性有哪些呢
網(wǎng)站網(wǎng)址:http://www.muchs.cn/article4/ghjhoe.html
成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián),為您提供做網(wǎng)站、網(wǎng)站改版、微信公眾號(hào)、響應(yīng)式網(wǎng)站、標(biāo)簽優(yōu)化、建站公司
聲明:本網(wǎng)站發(fā)布的內(nèi)容(圖片、視頻和文字)以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主,如果涉及侵權(quán)請(qǐng)盡快告知,我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng),如需處理請(qǐng)聯(lián)系客服。電話:028-86922220;郵箱:631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載,或轉(zhuǎn)載時(shí)需注明來源: 創(chuàng)新互聯(lián)