你發任你發,我用Java8,
jdk15的安裝和新版idea的安裝就不說了,下面奉上兩個軟體,
鏈接: https://pan.baidu.com/s/1hOb0CChSfYotFl3s3QL2yA 密碼: mp6a
安裝完成之后, java -version 查看版本確認環境無誤,

新版idea,需要額外做以下設定,


ok,環境已經ok,開始編碼,
這次發布的主要功能有:
Java 15為用戶提供了14項主要的增強/更改,包括一個范訓器模塊,三個預覽功能,兩個不推薦使用的功能以及兩個洗掉功能,
http://openjdk.java.net/projects/jdk/15/

對應中文特性:(JEP:JDK Enhancement Proposals,JDK 增強建議,也就是 JDK 的特性新增和改進提案,)
- JEP 339:EdDSA 數字簽名演算法
- JEP 360:密封類(預覽)
- JEP 371:隱藏類
- JEP 372:移除 Nashorn JavaScript 引擎
- JEP 373:重新實作 Legacy DatagramSocket API
- JEP 374:禁用偏向鎖定
- JEP 375:instanceof 模式匹配(第二次預覽)
- JEP 377:ZGC:一個可擴展的低延遲垃圾收集器
- JEP 378:文本塊
- JEP 379:Shenandoah:低暫停時間垃圾收集器
- JEP 381:移除 Solaris 和 SPARC 埠
- JEP 383:外部存盤器訪問 API(第二次范訓版)
- JEP 384:Records(第二次預覽)
- JEP 385:廢棄 RMI 激活機制
總結:
- 借用大佬的話:JDK15整體來看新特性方面并不算很亮眼,它主要是對之前版本 預覽特性 的功能做了確定,如文本塊、ZGC等,這么一來我們就可以放心大膽的使用了,
為什么大佬說本次新特性不算很亮眼呢?本次主要特性是以下六個:
JEP 360:密封類(預覽)、 ( 此概念其實也不是java語言首創,其他語言之前就有提到過)
JEP 371:隱藏類、 (此概念其實也不是java語言首創,其他語言之前就有提到過)
JEP 375:instanceof 模式匹配(第二次預覽)、
JEP 384:Records(第二次預覽)
JEP 377:ZGC:一個可擴展的低延遲垃圾收集器、 (之前的功能轉正)
JEP 378:文本塊、 ( 之前的功能轉正)
一、 JEP 360: Sealed Classes(Preview) 密封的類和介面(預覽)
用于限制超類的使用,密封的類和介面限制其它可能繼承或實作它們的其它類或介面,
具體使用:
因為我們引入了sealed class或interfaces,這些class或者interfaces只允許被指定的類或者interface進行擴展和實作,
使用修飾符sealed,您可以將一個類宣告為密封類,密封的類使用reserved關鍵字permits列出可以直接擴展它的類,子類可以 是最終的,非密封的或密封的,
之前我們的代碼是這樣的,
public class Person { } //人
class Teacher extends Person { }//教師
class Worker extends Person { } //工人
class Student extends Person{ } //學生
但是我們現在要限制 Person類 只能被這三個類繼承,不能被其他類繼承,需要這么做,
//添加sealed引數,permits后面跟上只能被繼承的子類名稱
public sealed class Person permits Teacher, Worker, Student{ } //人
//子類可以被修飾為 final
final class Teacher extends Person { }//教師
//子類可以被修飾為 non-sealed,此時 Worker類就成了普通類,誰都可以繼承它
non-sealed class Worker extends Person { } //工人
//任何類都可以繼承Worker
class AnyClass extends Worker{}
//子類可以被修飾為 sealed,同上
sealed class Student extends Person permits MiddleSchoolStudent,GraduateStudent{ } //學生
final class MiddleSchoolStudent extends Student { } //中學生
final class GraduateStudent extends Student { } //研究生
很強很實用的一個特性,可以限制類的層次結構,
二、JEP 371: Hidden Classes( 隱藏類)
該提案通過啟用標準 API 來定義 無法發現 且 具有有限生命周期 的隱藏類,從而提高 JVM 上所有語言的效率,JDK內部和外部的框架將能夠動態生成類,而這些類可以定義隱藏類,通常來說基于JVM的很多語言都有動態生成類的機制,這樣可以提高語言的靈活性和效率,
- 隱藏類天生為框架設計的,在運行時生成內部的class,
- 隱藏類只能通過反射訪問,不能直接被其他類的位元組碼訪問,
- 隱藏類可以獨立于其他類加載、卸載,這可以減少框架的記憶體占用,
Hidden Classes是什么呢?
Hidden Classes就是不能直接被其他class的二進制代碼使用的class,Hidden Classes主要被一些框架用來生成運行時類,但是這些類不是被用來直接使用的,而是通過反射機制來呼叫,
比如在JDK8中引入的lambda運算式,JVM并不會在編譯的時候將lambda運算式轉換成為專門的類,而是在運行時將相應的位元組碼動態生成相應的類物件,
另外使用動態代理也可以為某些類生成新的動態類,
那么我們希望這些動態生成的類需要具有什么特性呢?
- 不可發現性, 因為我們是為某些靜態的類動態生成的動態類,所以我們希望把這個動態生成的類看做是靜態類的一部分,所以我們不希望除了該靜態類之外的其他機制發現,
- 訪問控制, 我們希望在訪問控制靜態類的同時,也能控制到動態生成的類,
- 生命周期, 動態生成類的生命周期一般都比較短,我們并不需要將其保存和靜態類的生命周期一致,
API的支持
所以我們需要一些API來定義無法發現的且具有有限生命周期的隱藏類,這將提高所有基于JVM的語言實作的效率,
比如:
java.lang.reflect.Proxy可以定義隱藏類作為實作代理介面的代理類,
java.lang.invoke.StringConcatFactory可以生成隱藏類來保存常量連接方法;
java.lang.invoke.LambdaMetaFactory可以生成隱藏的nestmate類,以容納訪問封閉變數的lambda主體;
普通類是通過呼叫ClassLoader::defineClass創建的,而隱藏類是通過呼叫Lookup::defineHiddenClass創建的,這使JVM從提供的位元組中派生一個隱藏類,鏈接該隱藏類,并回傳提供對隱藏類的反射訪問的查找物件,呼叫程式可以通過回傳的查找物件來獲取隱藏類的Class物件,
三、Pattern Matching for instanceof (Second Preview) instanceof 自動匹配模式
在Java 14中作為預覽語言功能引入的instanceof模式匹配,在Java 15中處于第二次預覽,而沒有任何更改,
此特性我在java14新特性中寫過,詳情參考:java14新特性
舊寫法:
// 先判斷型別
if (obj instanceof String) {
// 然后轉換
String s = (String) obj;
// 然后才能使用
}
新寫法:( 自動匹配模式)
if (obj instanceof String s) {
// 如果型別匹配 直接使用
} else {
// 如果型別不匹配則不能直接使用
}
四、ZGC: A Scalable Low-Latency Garbage Collector (Production) ZGC 功能轉正
關注底層優化的小伙伴可以多注重此處,更多請看java14新特性之更多--ZGC
ZGC是Java 11引入的新的垃圾收集器(JDK9以后默認的垃圾回收器是G1),經過了多個實驗階段,自此終于成為正式特性,
自 2018 年以來,ZGC 已增加了許多改進,從并發類卸載、取消使用未使用的記憶體、對類資料共享的支持到改進的 NUMA 感知,此外,最大堆大小從 4 TB 增加到 16 TB,支持的平臺包括 Linux、Windows 和 MacOS,
ZGC是一個重新設計的并發的垃圾回收器,通過減少 GC 停頓時間來提高性能,
但是這并不是替換默認的GC,默認的GC仍然還是G1;之前需要通過-XX:+UnlockExperimentalVMOptions -XX:+UseZGC來啟用ZGC,現在只需要-XX:+UseZGC就可以,相信不久的將來它必將成為默認的垃圾回收器,
相關的引數有ZAllocationSpikeTolerance、ZCollectionInterval、ZFragmentationLimit、ZMarkStackSpaceLimit、ZProactive、ZUncommit、ZUncommitDelay ZGC-specific JFR events(ZAllocationStall、ZPageAllocation、ZPageCacheFlush、ZRelocationSet、ZRelocationSetGroup、ZUncommit)也從experimental變為product .
五、JEP 378:文本塊功能轉正
Text Blocks首次是在JDK 13中以預覽功能出現的,然后在JDK 14中又預覽了一次,終于在JDK 15中被確定下來,可放心使用了,
之前寫java14的時候已經寫過了,主要意思就是 可以把 sql、html、json、文章,直接丟到""" """ 里面,保留之前的格式,需要注意的是 length會在最后多出一個空格換行,瞄一眼
package com.hermanwang.java1;
import org.junit.Test;
/**
* @author hermanwang
* @create 2020-10-24
*/
public class TextBlocksTest {
@Test
public void test1(){
// 之前的寫法
String text1 = "The Sound of silence\n" +
"Hello darkness, my old friend\n" +
"I've come to talk with you again\n" +
"Because a vision softly creeping\n" +
"Left its seeds while I was sleeping\n" +
"And the vision that was planted in my brain\n" +
"Still remains\n" +
"Within the sound of silence";
System.out.println(text1);
//jdk13中的新特性:
String text2 = """
The Sound of silence
Hello darkness, my old friend
I've come to talk with you again
Because a vision softly creeping
Left its seeds while I was sleeping
And the vision that was planted in my brain
Still remains
Within the sound of silence\
""";
System.out.println();
System.out.println(text2);
System.out.println(text1.length());
System.out.println(text2.length());
}
//html
@Test
public void test2(){
String html1 = "<html lang=\"en\">\n" +
"<head>\n" +
" <meta charset=\"UTF-8\">\n" +
" <title>java14新特性</title>\n" +
"</head>\n" +
"<body>\n" +
" <p>hello,atguigu</p>\n" +
"</body>\n" +
"</html>";
//jdk13中的新特性:
String html2 = """
<html lang="en">
<head>
<meta charset="UTF-8">
<title>java14新特性</title>
</head>
<body>
<p>hello,atguigu</p>
</body>
</html>
""";
}
//json
@Test
public void test3() {
//jdk13之前的寫法
String myJson = "{\n" +
" \"name\":\"Song Hongkang\",\n" +
" \"address\":\"www.atguigu.com\",\n" +
" \"email\":\"shkstart@126.com\"\n" +
"}";
System.out.println(myJson);
//jdk13的新特性
String myJson1 = """
{
"name":"Song Hongkang",
"address":"www.atguigu.com",
"email":"shkstart@126.com"
}""";
System.out.println(myJson1);
}
//sql
@Test
public void test4(){
String sql = "SELECT id,NAME,email\n" +
"FROM customers\n" +
"WHERE id > 4\n" +
"ORDER BY email DESC";
//jdk13新特性:
String sql1 = """
SELECT id,NAME,email
FROM customers
WHERE id > 4
ORDER BY email DESC
""";
}
//jdk14新特性
@Test
public void test5(){
String sql1 = """
SELECT id,NAME,email
FROM customers
WHERE id > 4
ORDER BY email DESC
""";
System.out.println(sql1);
// \:取消換行操作
// \s:表示一個空格
String sql2 = """
SELECT id,NAME,email \
FROM customers\s\
WHERE id > 4 \
ORDER BY email DESC\
""";
System.out.println(sql2);
System.out.println(sql2.length());
}
}
六、JEP 384:Records Class(預覽)
Records Class 也是第二次出現的預覽功能,它在 JDK 14 中也出現過一次了,使用 Record 可以更方便的創建一個常量類,使用的前后代碼對比如下,
- 當你用Record 宣告一個類時,該類將自動擁有以下功能:
- 獲取成員變數的簡單方法,以上面代碼為例 name() 和 partner() ,注意區別于我們平常getter的寫法,
- 一個 equals 方法的實作,執行比較時會比較該類的所有成員屬性
- 重寫 equals 當然要重寫 hashCode
- 一個可以列印該類所有成員屬性的 toString 方法,
- 請注意只會有一個構造方法,
舊寫法:
package com.hermanwang.java1;
import java.util.Objects;
public class Point {
private final int x;
private final int y;
Point(int x, int y) {
this.x = x;
this.y = y;
}
int x() {
return x;
}
int y() {
return y;
}
public boolean equals(Object o) {
if (!(o instanceof Point))
return false;
Point other = (Point) o;
return other.x == x && other.y == y;
}
public int hashCode() {
return Objects.hash(x, y);
}
public String toString() {
return String.format("Point[x=%d,y=%d]", x,y);
}
}
新寫法:
record Point(int x, int y) {}
record其他特性如下:
package com.hermanwang.java1;
/**
* @author hermanwang
* @create 2020-10-24
*/
public record Customer(String name,Customer partner) {
//還可以宣告構造器、靜態的變數、靜態的方法、實體方法
public Customer(String name){
this(name,null);
}
public static String info;
public static void show(){
System.out.println("我是一個客戶");
}
public void showName(){
System.out.println("我的名字是:" + name());
}
//不可以在Record中定義實體變數
// public int id;
}
//Record不可以宣告為abstract的
//abstract record User(){}
//Record不可以顯式的繼承于其他類
//record User() extends Thread{}
好了 至此,主要的六個新特性已經完了,剩下的是 其他的不是很重要的8個新特性,
以下特性僅了解即可,
七、JEP 339:Edwards-Curve Digital Signature Algorithm(EdDSA 數字簽名演算法)
這是一個新的功能,
新加入基于Edwards-Curve數字簽名演算法(EdDSA-Edwards-Curve Digital Signature Algorithm)的加密簽名,即愛德華茲曲線數字簽名演算法, 在許多其它加密庫(如 OpenSSL 和 BoringSSL)中得到支持,
與 JDK 中的現有簽名方案相比,EdDSA 具有更高的安全性和性能,因此備受關注,它已經在OpenSSL和BoringSSL等加密庫中得到支持,在區塊鏈領域用的比較多,
EdDSA是一種現代的橢圓曲線方案,具有JDK中現有簽名方案的優點,EdDSA將只在SunEC提供商中實作,
八、JEP 373:Reimplement the Legacy DatagramSocket API(重新實作 DatagramSocket API)
新的計劃是JEP 353的后續,該方案重新實作了遺留的套接字API,
java.net.datagram.Socket和java.net.MulticastSocket的當前實作可以追溯到JDK 1.0,那時IPv6還在開發中,因此,當前的多播套接字實作嘗試調和IPv4和IPv6難以維護的方式,
- 通過替換 java.net.datagram 的基礎實作,重新實作舊版 DatagramSocket API,
- 更改java.net.DatagramSocket 和 java.net.MulticastSocket 為更加簡單、現代化的底層實作,提高了 JDK 的可維護性和穩定性,
通過將java.net.datagram.Socket和java.net.MulticastSocket API的底層實作替換為更簡單、更現代的實作來重新實作遺留的DatagramSocket API,
新的實作:1.易于除錯和維護;2.與Project Loom中正在探索的虛擬執行緒協同,
九、JEP 374: Disable and Deprecate Biased Locking 禁用偏向鎖定
在默認情況下禁用偏向鎖定,并棄用所有相關命令列選項,目標是確定是否需要繼續支持偏置鎖定的 高維護成本 的遺留同步優化, HotSpot虛擬機使用該優化來減少非競爭鎖定的開銷, 盡管某些Java應用程式在禁用偏向鎖后可能會出現性能下降,但偏向鎖的性能提高通常不像以前那么明顯,
該特性默認禁用了biased locking(-XX:+UseBiasedLocking),并且廢棄了所有相關的命令列選型(BiasedLockingStartupDelay, BiasedLockingBulkRebiasThreshold, BiasedLockingBulkRevokeThreshold, BiasedLockingDecayTime, UseOptoBiasInlining, PrintBiasedLockingStatistics and PrintPreciseBiasedLockingStatistics)
十、JEP 379:Shenandoah:低暫停時間垃圾收集器 轉正
Shenandoah垃圾回收演算法終于從實驗特性轉變為產品特性,這是一個從 JDK 12 引入的回收演算法,該演算法通過與正在運行的 Java 執行緒同時進行疏散作業來減少 GC 暫停時間,Shenandoah 的暫停時間與堆大小無關,無論堆疊是 200 MB 還是 200 GB,都具有相同的一致暫停時間,
怎么形容Shenandoah和ZGC的關系呢?異同點大概如下:
- 相同點:性能幾乎可認為是相同的
- 不同點:ZGC是Oracle JDK的,而Shenandoah只存在于OpenJDK中,因此使用時需注意你的JDK版本
打開方式:使用-XX:+UseShenandoahGC命令列引數打開,
Shenandoah在JDK12被作為experimental引入,在JDK15變為Production;之前需要通過-XX:+UnlockExperimentalVMOptions -XX:+UseShenandoahGC來啟用,現在只需要-XX:+UseShenandoahGC即可啟用
十一、JEP 383: Foreign-Memory Access API 外部存盤器訪問 API(范訓器版)
目的是引入一個 API,以允許 Java 程式安全、有效地訪問 Java 堆之外的外部存盤器,如本機、持久和托管堆,
有許多Java程式是訪問外部記憶體的,比如Ignite和MapDB, 該API將有助于避免與垃圾收集相關的成本以及與跨行程共享記憶體以及通過將檔案映射到記憶體來序列化和反序列化記憶體內容相關的不可預測性 ,該Java API目前沒有為訪問外部記憶體提供令人滿意的解決方案,但是在新的提議中,API不應該破壞JVM的安全性,
Foreign-Memory Access API在JDK14被作為incubating API引入,在JDK15處于Second Incubator,提供了改進,
十二、JEP 381:Remove the Solaris and SPARC Ports (移除 Solaris 和 SPARC 埠)
洗掉對Solaris/SPARC、Solaris/x64和Linux/SPARC埠的源代碼和構建支持,在JDK 14中被標記為廢棄,在JDK15版本正式移除, 許多正在開發的專案和功能(如Valhalla、Loom和Panama)需要進行重大更改以適應CPU架構和作業系統特定代碼,
近年來,Solaris 和 SPARC 都已被 Linux 作業系統和英特爾處理器取代,放棄對 Solaris 和 SPARC 埠的支持將使 OpenJDK 社區的貢獻者能夠加速開發新功能,從而推動平臺向前發展,
十三、JEP 372:Remove the Nashorn JavaScript Engine
Nashorn是在JDK提出的腳本執行引擎,該功能是 2014 年 3 月發布的 JDK 8 的新特性,在JDK11就已經把它標記為廢棄了,JDK15完全移除,
在JDK11中取以代之的是GraalVM,GraalVM是一個運行時平臺,它支持Java和其他基于Java位元組碼的語言,但也支持其他語言,如JavaScript,Ruby,Python或LLVM,性能是Nashorn的2倍以上,
JDK15移除了Nashorn JavaScript Engine及jjs 命令列工具,具體就是jdk.scripting.nashorn及jdk.scripting.nashorn.shell這兩個模塊被移除了,
十四、JEP 385:Deprecate RMI Activation for Removal
RMI Activation被標記為Deprecate,將會在未來的版本中洗掉,RMI激活機制是RMI中一個過時的部分,自Java 8以來一直是可選的而非必選項,RMI激活機制增加了持續的維護負擔,RMI的其他部分暫時不會被棄用,
RMI jdk1.2引入,EJB在RMI系統中,我們使用延遲激活,延遲激活將激活物件推遲到客戶第一次使用(即第一次方法呼叫)之前, 既然RMI Activation這么好用,為什么要廢棄呢?
因為對于現代應用程式來說,分布式系統大部分都是基于Web的,web服務器已經解決了穿越防火墻,過濾請求,身份驗證和安全性的問題,并且也提供了很多延遲加載的技術,
所以在現代應用程式中,RMI Activation已經很少被使用到了,并且在各種開源的代碼庫中,也基本上找不到RMI Activation的使用代碼了, 為了減少RMI Activation的維護成本,在JDK8中,RMI Activation被置為可選的,現在在JDK15中,終于可以廢棄了,
完,測驗代碼地址:https://github.com/cyberHermanwang/Java15Feature
感謝尚硅谷!
轉載請註明出處,本文鏈接:https://www.uj5u.com/qita/190461.html
標籤:其他
