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