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