本篇內(nèi)容介紹了“JDK12的新特性詳解”的有關(guān)知識,在實際案例的操作過程中,不少人都會遇到這樣的困境,接下來就讓小編帶領(lǐng)大家學習一下如何處理這些情況吧!希望大家仔細閱讀,能夠?qū)W有所成!
定義:
添加一個名為Shenandoah的新垃圾收集(GC)算法,通過與正在運行的Java線程同時進行疏散工作 來減少GC暫停時間。使用Shenandoah的暫停時間與堆大小無關(guān),這意味著無論堆是200MB還是200GB,都 將具有相同的一致暫停時間。
非目標:
這不是一個統(tǒng)治所有人的GC。還有其他垃圾收集算法可以優(yōu)先考慮吞吐量或內(nèi)存占用而不是響應(yīng)性。 Shenandoah是適用于評估響應(yīng)性和可預(yù)測的短暫停頓的應(yīng)用程序的算法。目標不是解決所有JVM暫停問 題。由于GC之外的其他原因(例如安全時間點(TTSP)發(fā)布或監(jiān)控通脹)而暫停時間超出了此JEP的范圍。
構(gòu)建和調(diào)用:
作為實驗性功能,Shenandoah將-XX:+UnlockExperimentalVMOptions在命令行中要求。Shenandoah構(gòu)建系統(tǒng)會自動禁用不受 支持的配置。下游建設(shè)者可以選擇--with-jvm-features=-shenandoahgc在其他支持的平臺上禁用構(gòu)建Shenandoah。 要啟用/使用Shenandoah GC,需要以下JVM選項:-XX:+UnlockExperimentalVMOptions -XX:+UseShenandoahGC
定義:
在JDK源代碼中添加一套基本的微基準測試,使開發(fā)人員可以輕松運行現(xiàn)有的微基準測試并創(chuàng) 建新的基準測試。
目標:
1、基于[Java Microbenchmark線束(JMH)] [1] 2、穩(wěn)定且經(jīng)過調(diào)整的基準測試,針對持續(xù)性能測試 2.1、在功能發(fā)布的功能完成里程碑之后,以及非功能版本之后的穩(wěn)定且不移動的套件 2.2、支持與先前JDK版本的適用測試比較 3、簡單 3.1 輕松添加新基準 3.2 在API和選項更改,不推薦使用或在開發(fā)期間刪除時,可以輕松更新測試 3.3 易于構(gòu)建 3.4 易于查找和運行基準 3.5 支持JMH更新 3.6 在套件中包含大約一百個基準的初始集
預(yù)覽功能,如果該jdk12的switch效果不好的話,會被下一版本jdk13直接移除該功能,并不是之后每個版本必須的。
許多break使它不必要地冗長,如果忘記寫break,則會產(chǎn)生意料之外的結(jié)果或者異常,所以針對于此jdk12在這里進行了優(yōu)化升級。
JDK12之前的版本:
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; }
JDK12:我們建議引入一種新形式的開關(guān)標簽,寫成“case L ->”表示如果標簽匹配,則只執(zhí)行標簽右側(cè)的代碼。
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); }
許多Switch表達式,每個case都會賦值給一個變量或者執(zhí)行某種操作,如下是賦值給numLetters變量具體值。
JDK12之前:
int numLetters;switch (day) { case MONDAY: case FRIDAY: case SUNDAY: numLetters = 6; break; case TUESDAY: numLetters = 7; break; case THURSDAY: case SATURDAY: numLetters = 8; break; case WEDNESDAY: numLetters = 9; break; default: throw new IllegalStateException("Wat: " + day); }
JDK12:將此表達為一種陳述是迂回的,重復(fù)的,并且容易出錯。意味著我們應(yīng)該計算numLetters每一天的價值。應(yīng)該可以直接說,使用更清晰,更安全Switch表達式
int numLetters = switch (day) { case MONDAY, FRIDAY, SUNDAY -> 6; case TUESDAY -> 7; case THURSDAY, SATURDAY -> 8; case WEDNESDAY -> 9; };
如果將它用在方法上,則可以為:
static void howMany(int k) { switch (k) { case 1 -> System.out.println("one"); case 2 -> System.out.println("two"); case 3 -> System.out.println("many"); } }
或者類上,我想到的這個switch這個功能可以用在抽象工廠類方面。
T result = switch (arg) { case L1 -> e1; case L2 -> e2; default -> e3;};
摘要:
引入API來模擬關(guān)鍵類文件和運行時工件的名義描述,特別是可從常量池加載的常量。
動機:
每個Java類文件都有一個常量池,用于存儲類中字節(jié)碼指令的操作數(shù)。從廣義上講,常量池中的條目描述了運行 時工件(如類和方法)或簡單值(如字符串和整數(shù))。所有這些條目都稱為可加載常量,因為它們可以作為ldc指令的 操作數(shù)(“加載常量”)。 它們也可能出現(xiàn)在invokedynamic指令的bootstrap方法的靜態(tài)參數(shù)列表中。執(zhí)行一個ldc或invokedynamic指令 導(dǎo)致加載常數(shù)被解析成一個標準的Java類,如“活”的值Class,String或int。 操作class文件的程序需要對字節(jié)碼指令進行建模,并依次對可加載的常量進行建模。但是,使用標準Java類型 來模擬可加載常量是不合適的。 描述字符串(CONSTANT_String_info條目)的可加載常量可能是可以接受的,因為生成“實時” String對象 很簡單,但是對于描述類(CONSTANT_Class_info條目)的可加載常量是有問題的,因為產(chǎn)生“實時”ClassObject 依賴于類加載的正確性和一致性。 不幸的是,類加載有許多環(huán)境依賴和失敗模式:所需的類不存在或者請求者可能無法訪問; 類加載的結(jié)果因上下文 而異; 裝載類有副作用;有時類加載可能根本不可能(例如當所描述的類尚不存在或者無法加載時,如在編譯那些相同類 或在jlink轉(zhuǎn)換期間)。 因此,處理可加載常量的程序如果能夠以純粹的名義符號形式操作類和方法,以及不太知名的工件(如方法句柄和動 態(tài)計算常量),則會更簡單: 1、字節(jié)碼解析和生成庫必須以符號形式描述類和方法句柄。如果沒有標準機制,它們必須采用ad-hoc機制,無論是 ASM的描述符類型Handle,還是字符串元組(方法所有者,方法名稱,方法描述符),或者這些機制的特殊(并且容易出 錯)編碼單個字符串。 2、如果它們可以在符號域中工作而不是使用“實時”類和方法句柄,invokedynamic那么通過旋轉(zhuǎn)字節(jié)碼(例如LambdaMetafactory)來操作的Bootstraps 將更簡單。 3、編譯器和脫機轉(zhuǎn)換器(例如jlink插件)需要描述無法加載到正在運行的VM的類的類和成員。編譯器插件(例如注 釋處理器)同樣需要用符號術(shù)語來描述程序元素。
摘要:
arm64在保留32位ARM端口和64位aarch74端口的同時,刪除與端口相關(guān)的所有源。
動機:
刪除此端口將允許所有貢獻者將他們的精力集中在單個64位ARM實現(xiàn)上,并消除維護兩個端口所需的重復(fù)工作。
摘要:
在64位平臺上使用默認類列表增強JDK構(gòu)建過程以生成類數(shù)據(jù)共享(CDS)歸檔。
目標:
1、改善開箱即用的啟動時間 2、消除用戶運行-Xshare:dump以從CDS中受益的需要
摘要:
如果G1混合集合可能超過暫停目標,則使其可以中止。
動機:
G1的目標之一是滿足用戶提供的暫停時間目標以暫停其收集暫停。G1使用高級分析引擎來選擇在集合期間 要完成的工作量(這部分基于應(yīng)用程序行為)。此選擇的結(jié)果是一組稱為集合集的區(qū)域。一旦確定了集合集并且 已經(jīng)開始集合,則G1必須在不停止的情況下收集集合集的所有區(qū)域中的所有活動對象。如果啟發(fā)式選擇過大的收 集,則此行為可導(dǎo)致G1超過暫停時間目標,例如,如果應(yīng)用程序的行為發(fā)生變化,以致啟發(fā)式工作在“陳舊”數(shù)據(jù) 上,則可能發(fā)生這種情況。特別是在混合集合期間可以觀察到這種情況,其中集合集通??梢园嗯f區(qū)域。 需要一種機制來檢測啟發(fā)式方法何時反復(fù)為集合選擇錯誤的工作量,如果是,則讓G1逐步遞增地執(zhí)行收集工作, 其中集合可以在每個步驟之后中止。這種機制將允許G1更頻繁地滿足暫停時間目標。
摘要:
增強G1垃圾收集器,以便在空閑時自動將Java堆內(nèi)存返回給操作系統(tǒng)。
成功指標:
如果應(yīng)用程序活動非常低,G1應(yīng)該在合理的時間段內(nèi)釋放未使用的Java堆內(nèi)存。
動機:
目前G1垃圾收集器可能無法及時將已提交的Java堆內(nèi)存返回給操作系統(tǒng)。G1僅在完整GC或并發(fā)周期內(nèi) 從Java堆返回內(nèi)存。由于G1很難完全避免完整的GC,并且只觸發(fā)基于Java堆占用和分配活動的并發(fā)周期, 因此在許多情況下它不會返回Java堆內(nèi)存,除非在外部強制執(zhí)行此操作。 在使用資源支付的容器環(huán)境中,這種行為特別不利。即使在VM由于不活動而僅使用其分配的內(nèi)存資源的 一小部分的階段,G1也將保留所有Java堆。這導(dǎo)致客戶始終為所有資源付費,云提供商無法充分利用其硬件。 如果VM能夠檢測到Java堆的利用率不足(“空閑”階段),并在此期間自動減少其堆使用量,則兩者都 將受益。 Shenandoah和OpenJ9的GenCon收集器已經(jīng)提供了類似的功能。
JDK 12版本包括對Unicode 11.0.0的支持。在發(fā)布支持Unicode 10.0.0的JDK 11之后,Unicode 11.0.0引入了以下JDK 12中包含的新功能:
1、684個新角色 1.1、66個表情符號字符 1.2、Copyleft符號 1.3、評級系統(tǒng)的半星 1.4、額外的占星符號 1.5、象棋中國象棋符號 2、11個新區(qū)塊 2.1、格魯吉亞擴展 2.2、瑪雅數(shù)字 2.3、印度Siyaq數(shù)字 2.4、國際象棋符號 3、7個新腳本 3.1、Hanifi Rohingya 3.2、Old Sogdian 3.3、Sogdian 3.4、Dogra 3.5、Gunjala Gondi 3.6、Makasar 3.7、Medefaidrin
NumberFormat添加了對以緊湊形式格式化數(shù)字的支持。緊湊數(shù)字格式是指以簡短或人類可 讀形式表示的數(shù)字。例如,在en_US語言環(huán)境中,1000可以格式化為“1K”,1000000可以格式化 為“1M”,具體取決于指定的樣式NumberFormat.Style。緊湊數(shù)字格式由LDML的Compact Number格式規(guī)范定義。要獲取實例,請使用NumberFormat緊湊數(shù)字格式所給出的工廠方法之一。 例如:NumberFormat fmt = NumberFormat.getCompactNumberInstance(Locale.US, NumberFormat.Style.SHORT);String result = fmt.format(1000); 上面的例子導(dǎo)致“1K”。
禁止并允許java.security.manager系統(tǒng)屬性的選項
新的“disallow”和“allow”令牌選項已添加到j(luò)ava.security.manager系統(tǒng)屬性中。 在JDK實現(xiàn)中,如果Java虛擬機以系統(tǒng)屬性java.security.manager設(shè)置為“disallow”開始, 則該System.setSecurityManager方法不能用于設(shè)置安全管理器并將拋出 UnsupportedOperationException?!癲isallow”選項可以提高從未設(shè)置安全管理器的應(yīng)用程 序的運行時性能。
groupname選項添加到keytool密鑰對生成
-groupname添加了一個新選項,keytool -genkeypair以便用戶在生成密鑰對時可以指 定命名組。例如,keytool -genkeypair -keyalg EC -groupname secp384r1將使用 secp384r1曲線生成EC密鑰對。由于可能存在多個具有相同大小的曲線,因此使用該-groupname 選項優(yōu)先于該-keysize選項。
新Java飛行記錄器(JFR)安全事件
略過...
自定義PKCS12密鑰庫生成
添加了新的系統(tǒng)和安全屬性,使用戶能夠自定義PKCS#12密鑰庫的生成。這包括用于密鑰保護, 證書保護和MacData的算法和參數(shù)??梢栽谖募摹癙KCS12 KeyStore屬性”部分中找到這些屬性的 詳細說明和可能的值java.security。
ChaCha20和Poly1305 TLS密碼
JSSE中添加了使用ChaCha20-Poly1305算法的新TLS密碼套件。默認情況下啟用這些密碼套件。 TLS_CHACHA20_POLY1305_SHA256密碼套件適用于TLS 1.3。
在krb5.conf中支持dns_canonicalize_hostname
該dns_canonicalize_hostname標志中krb5.conf的配置文件現(xiàn)在是由JDK Kerberos實現(xiàn)支持。 設(shè)置為“true”時,服務(wù)主體名稱中的短主機名將被規(guī)范化為完全限定的域名(如果可用)。否則,不執(zhí)行規(guī) 范化。默認值是true”。這也是JDK 12之前的行為。
核心庫/ java.util.jar中,刪除java.util.ZipFile / Inflator / Deflator中的finalize方法
該finalize方法在java.util.ZipFile,java.util.Inflator和java.util.Deflator是在JDK9 棄用用于移除及其執(zhí)行了更新,是一個空操作。該finalize在方法java.util.ZipFile,java.util.Inflator 以及java.util.Deflator在此版本中被刪除。finalize應(yīng)修改為執(zhí)行清理而重寫的子類,以使用備用清理機制并 刪除寫finalize方法。 finalize方法,去除將暴露Object.finalize到的子類ZipFile,Deflater和Inflater。finalize由于 聲明的異常發(fā)生更改,可能會在覆蓋時發(fā)生編譯錯誤。Object.finalize現(xiàn)在宣布投擲java.lang.Throwable。 以前,只有java.io.IOException宣布。
核心庫/ java.io,從FileInputStream和FileOutputStream中刪除finalize方法
該finalize方法FileInputStream和FileOutputStream被棄用去除JDK 9.他們已經(jīng)在此版本中被刪除。 所述java.lang.ref.Cleaner,自JDK9的主要機制已被實施,以關(guān)閉文件描述符不再從可到達的FileInputStream和FileOutputStream。關(guān)閉文件的推薦方法是顯式調(diào)用close或使用try-with-resources。
工具/ javac的刪除javac支持6 / 1.6源,目標和發(fā)布值
javac的6/1.6的參數(shù)值的支持-source,-target以及--release標志已被刪除。
“JDK12的新特性詳解”的內(nèi)容就介紹到這里了,感謝大家的閱讀。如果想了解更多行業(yè)相關(guān)的知識可以關(guān)注創(chuàng)新互聯(lián)-成都網(wǎng)站建設(shè)公司網(wǎng)站,小編將為大家輸出更多高質(zhì)量的實用文章!
文章題目:JDK12的新特性詳解-創(chuàng)新互聯(lián)
文章路徑:http://chinadenli.net/article34/dojhse.html
成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián),為您提供建站公司、小程序開發(fā)、網(wǎng)站改版、關(guān)鍵詞優(yōu)化、響應(yīng)式網(wǎng)站、動態(tài)網(wǎng)站
聲明:本網(wǎng)站發(fā)布的內(nèi)容(圖片、視頻和文字)以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主,如果涉及侵權(quán)請盡快告知,我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場,如需處理請聯(lián)系客服。電話:028-86922220;郵箱:631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載,或轉(zhuǎn)載時需注明來源: 創(chuàng)新互聯(lián)