文章目錄

• 前言
• 一、Java8的新特性
• • • Lambda 表達(dá)式
    • 方法引用
    • 函數(shù)式接口實(shí)例
    • Java 8 默認(rèn)方法
    • Stream
    • Optional 類
    • Nashorn JavaScript
    • 日期時(shí)間 API
    • Base64
• 二、Java11的新特性
• • • ZGC
    • Flight Recorder（JFR）
    • Low-Overhead Heap Profiling
    • HTTP/2 Client API
    • Transport Layer Security (TLS) 1.3
    • Improve Aarch64 Intrinsics
    • Epsilon: A No-Op Garbage Collector(Experimental)
    • Launch Single-File Source-Code Programs
    • Unicode 10
    • Nest-Based Access Control
    • Dynamic Class-File Constants
    • Remove the Java EE and CORBA Modules
    • Deprecate the Nashorn JavaScript Engine
    • Deprecate the Pack200 Tools and API
• 總結(jié)

---

前言

目前市場(chǎng)上主流的穩(wěn)定版主要是Java 8和Java 11。

---

一、Java8的新特性

Lambda 表達(dá)式

Lambda 表達(dá)式，也可稱為閉包，它是推動(dòng) Java 8 發(fā)布的最重要新特性，Lambda 允許把函數(shù)作為一個(gè)方法的參數(shù)（函數(shù)作為參數(shù)傳遞進(jìn)方法中），使用Lambda 表達(dá)式可以使代碼變的更加簡(jiǎn)潔緊湊。

方法引用

方法引用通過方法的名字來指向一個(gè)方法，方法引用可以使語(yǔ)言的構(gòu)造更緊湊簡(jiǎn)潔，減少冗余代碼，方法引用使用一對(duì)冒號(hào) :: 。

函數(shù)式接口實(shí)例

Predicate 接口是一個(gè)函數(shù)式接口，它接受一個(gè)輸入?yún)?shù) T，返回一個(gè)布爾值結(jié)果。該接口包含多種默認(rèn)方法來將Predicate組合成其他復(fù)雜的邏輯（比如：與，或，非）。該接口用于測(cè)試對(duì)象是 true 或 false。

Java 8 默認(rèn)方法

Java 8 新增了接口的默認(rèn)方法。簡(jiǎn)單說，默認(rèn)方法就是接口可以有實(shí)現(xiàn)方法，而且不需要實(shí)現(xiàn)類去實(shí)現(xiàn)其方法。我們只需在方法名前面加個(gè)default關(guān)鍵字即可實(shí)現(xiàn)默認(rèn)方法。

Stream

Stream使用一種類似用SQL語(yǔ)句從數(shù)據(jù)庫(kù)查詢數(shù)據(jù)的直觀方式來提供一種對(duì)Java集合運(yùn)算和表達(dá)的高階抽象。Stream API可以極大提高Java程序員的生產(chǎn)力，讓程序員寫出高效率、干凈、簡(jiǎn)潔的代碼。這種風(fēng)格將要處理的元素集合看作一種流，流在管道中傳輸，并且可以在管道的節(jié)點(diǎn)上進(jìn)行處理，比如篩選，排序，聚合等。元素流在管道中經(jīng)過中間操作（intermediate operation）的處理，最后由最終操作(terminal operation)得到前面處理的結(jié)果。

Optional 類

Optional 類是一個(gè)可以為null的容器對(duì)象。如果值存在則isPresent()方法會(huì)返回true，調(diào)用get()方法會(huì)返回該對(duì)象。Optional 是個(gè)容器：它可以保存類型T的值，或者僅僅保存null。Optional提供很多有用的方法，這樣我們就不用顯式進(jìn)行空值檢測(cè)。Optional 類的引入很好的解決空指針異常。

Nashorn JavaScript

Nashorn 一個(gè) javascript 引擎。從JDK1.8開始，Nashorn取代Rhino(JDK 1.6, JDK1.7)成為Java的嵌入式JavaScript引擎。Nashorn完全支持ECMAScript 5.1規(guī)范以及一些擴(kuò)展。它使用基于JSR292的新語(yǔ)言特性，其中包含在JDK 7中引入的 invokedynamic，將JavaScript編譯成Java字節(jié)碼。與先前的Rhino實(shí)現(xiàn)相比，這帶來了2到10倍的性能提升。

日期時(shí)間 API

Java 8通過發(fā)布新的Date-Time API (JSR 310)來進(jìn)一步加強(qiáng)對(duì)日期與時(shí)間的處理。
在舊版的Java 中，日期時(shí)間API 存在諸多問題，其中有：

非線程安全 ? java.util.Date 是非線程安全的，所有的日期類都是可變的，這是Java日期類最大的問題之一。

設(shè)計(jì)很差 ? Java的日期/時(shí)間類的定義并不一致，在java.util和java.sql的包中都有日期類，此外用于格式化和解析的類在java.text包中定義。java.util.Date同時(shí)包含日期和時(shí)間，而java.sql.Date僅包含日期，將其納入java.sql包并不合理。另外這兩個(gè)類都有相同的名字，這本身就是一個(gè)非常糟糕的設(shè)計(jì)。

時(shí)區(qū)處理麻煩 ? 日期類并不提供國(guó)際化，沒有時(shí)區(qū)支持，因此Java引入了java.util.Calendar和java.util.TimeZone類，但他們同樣存在上述所有的問題。
Java 8 在 java.time 包下提供了很多新的 API。以下為兩個(gè)比較重要的 API：

Local(本地) ? 簡(jiǎn)化了日期時(shí)間的處理，沒有時(shí)區(qū)的問題。

Zoned(時(shí)區(qū)) ? 通過制定的時(shí)區(qū)處理日期時(shí)間。
新的java.time包涵蓋了所有處理日期，時(shí)間，日期/時(shí)間，時(shí)區(qū)，時(shí)刻（instants），過程（during）與時(shí)鐘（clock）的操作。

Base64

在Java8中，Base64編碼已經(jīng)成為Java類庫(kù)的標(biāo)準(zhǔn)。
Java 8 內(nèi)置了 Base64 編碼的編碼器和解碼器。
Base64工具類提供了一套靜態(tài)方法獲取下面三種BASE64編解碼器：

基本：輸出被映射到一組字符A-Za-z0-9+/，編碼不添加任何行標(biāo)，輸出的解碼僅支持A-Za-z0-9+/。

URL：輸出映射到一組字符A-Za-z0-9+_，輸出是URL和文件。

MIME：輸出隱射到MIME友好格式。輸出每行不超過76字符，并且使用’\r’并跟隨’\n’作為分割。編碼輸出最后沒有行分割。

二、Java11的新特性

ZGC

JDK11 引入了兩種新的 GC，其中包括也許是劃時(shí)代意義的 ZGC，雖然其目前還是實(shí)驗(yàn)特性，但是從能力上來看，這是 JDK 的一個(gè)巨大突破，為特定生產(chǎn)環(huán)境的苛刻需求提供了一個(gè)可能的選擇。例如，對(duì)部分企業(yè)核心存儲(chǔ)等產(chǎn)品，如果能夠保證不超過 10ms 的 GC 暫停，可靠性會(huì)上一個(gè)大的臺(tái)階，這是過去我們進(jìn)行 GC 調(diào)優(yōu)幾乎做不到的，是能與不能的問題。對(duì)于 G1 GC，相比于 JDK 8，升級(jí)到 JDK 11 即可享受到：并行的 Full GC，快速的 CardTable 掃描，自適應(yīng)的堆占用比例調(diào)整（IHOP），在并發(fā)標(biāo)記階段的類型卸載等等。這些都是針對(duì) G1 的不斷增強(qiáng)，其中串行 Full GC 等甚至是曾經(jīng)被廣泛詬病的短板，你會(huì)發(fā)現(xiàn) GC 配置和調(diào)優(yōu)在 JDK11 中越來越方便。

Flight Recorder（JFR）

Flight Recorder（JFR）是 Oracle 剛剛開源的強(qiáng)大特性。JFR 是一套集成進(jìn)入 JDK、JVM 內(nèi)部的事件機(jī)制框架，通過良好架構(gòu)和設(shè)計(jì)的框架，硬件層面的極致優(yōu)化，生產(chǎn)環(huán)境的廣泛驗(yàn)證，它可以做到極致的可靠和低開銷。在 SPECjbb2015 等基準(zhǔn)測(cè)試中，JFR 的性能開銷最大不超過 1%，所以，工程師可以基本沒有心理負(fù)擔(dān)地在大規(guī)模分布式的生產(chǎn)系統(tǒng)使用，這意味著，我們既可以隨時(shí)主動(dòng)開啟 JFR 進(jìn)行特定診斷，也可以讓系統(tǒng)長(zhǎng)期運(yùn)行 JFR，用以在復(fù)雜環(huán)境中進(jìn)行“After-the-fact”分析。
在保證低開銷的基礎(chǔ)上，JFR 提供的能力可以應(yīng)用在對(duì)鎖競(jìng)爭(zhēng)、阻塞、延遲，JVM GC、SafePoint 等領(lǐng)域，進(jìn)行非常細(xì)粒度分析。甚至深入 JIT Compiler 內(nèi)部，全面把握熱點(diǎn)方法、內(nèi)聯(lián)、逆優(yōu)化等等。JFR 提供了標(biāo)準(zhǔn)的 Java、C++ 等擴(kuò)展 API，可以與各種層面的應(yīng)用進(jìn)行定制、集成，為復(fù)雜的企業(yè)應(yīng)用棧或者復(fù)雜的分布式應(yīng)用，提供 All-in-One 解決方案。而這一切都是內(nèi)建在 JDK 和 JVM 內(nèi)部的，并不需要額外的依賴，開箱即用。

Low-Overhead Heap Profiling

它來源于 Google 等業(yè)界前沿廠商的一線實(shí)踐，通過獲取對(duì)象分配細(xì)節(jié)，為 JDK 補(bǔ)足了對(duì)象分配診斷方面的一些短板，工程師可以通過 JVMTI 使用這個(gè)能力增強(qiáng)自身的工具。

HTTP/2 Client API

新的 HTTP API 提供了對(duì) HTTP/2 等業(yè)界前沿標(biāo)準(zhǔn)的支持，精簡(jiǎn)而又友好的 API 接口，與主流開源 API（如，Apache HttpClient， Jetty， OkHttp 等）對(duì)等甚至更高的性能。與此同時(shí)它是 JDK 在 Reactive-Stream 方面的第一個(gè)生產(chǎn)實(shí)踐，廣泛使用了 Java Flow API 等，終于讓 Java 標(biāo)準(zhǔn) HTTP 類庫(kù)在擴(kuò)展能力等方面，滿足了現(xiàn)代互聯(lián)網(wǎng)的需求。

Transport Layer Security (TLS) 1.3

就是安全類庫(kù)、標(biāo)準(zhǔn)等方面的大范圍升級(jí)，它還是中國(guó)安全專家范學(xué)雷所領(lǐng)導(dǎo)的 JDK 項(xiàng)目，完全不同于以往的修修補(bǔ)補(bǔ)，是個(gè)非常大規(guī)模的工程。
Dynamic Class-File Constants
動(dòng)態(tài) class 文件常量。擴(kuò)展了 Java class 文件格式，支持一種新的常量池形式：CONSTANT_Dynamic。

Improve Aarch64 Intrinsics

主要是針對(duì) ARM Aarch64 架構(gòu)的優(yōu)化，比如提供優(yōu)化的 sin、cos 等函數(shù)。

Epsilon: A No-Op Garbage Collector(Experimental)

無操作的垃圾收集器。Epsilon 是一個(gè)特殊的垃圾收集器，只處理內(nèi)存分配，不負(fù)責(zé)回收。一旦堆耗盡，就關(guān)閉 JVM。聽上去這個(gè)收集器好像沒什么意義。不過它還是有不少用處的。比如：性能測(cè)試。GC 會(huì)影響性能，有了這么一個(gè)幾乎什么都不干的 GC，我們可以過濾掉 GC 帶來的影響因素。還有些性能因素不是 GC 引入的，比如編譯器變換，利用 Epsilon GC，我們可以對(duì)比。就像生物學(xué)里做實(shí)驗(yàn)，我們可以用它做一個(gè)對(duì)照組。另外還有內(nèi)存壓力測(cè)試、VM接口測(cè)試等。

Launch Single-File Source-Code Programs

支持運(yùn)行單個(gè)文件中的源代碼。在剛學(xué)習(xí) Java 或者編寫小的工具程序時(shí)，我們一般要先用 javac 編譯源文件，再用 java 命令運(yùn)行。有了這個(gè)功能，我們可以直接用 java 命令運(yùn)行源程序。

Unicode 10

升級(jí)現(xiàn)有 API 支持 Unicode 10。Java SE 10 實(shí)現(xiàn)的是 Unicode 8.0。與 Java 10 相比，Java 11 多支持 16 018 個(gè)新字符，10 種新的文字類型。

Nest-Based Access Control

基于嵌套的訪問控制。Java 11 引入了 nest 的概念，這是一個(gè)新的訪問控制上下文（context），邏輯上處于同一代碼實(shí)體中的類，盡管會(huì)被編譯為不同的 class 文件，但是可以訪問彼此的 private 成員，不再需要編譯器插入輔助訪問的橋方法。

Dynamic Class-File Constants

動(dòng)態(tài) class 文件常量。擴(kuò)展了 Java class 文件格式，支持一種新的常量池形式：CONSTANT_Dynamic。

Remove the Java EE and CORBA Modules

將 Java SE 9 中標(biāo)記為廢棄的 Java EE 和 CORBA 正式從 Java SE 平臺(tái)中刪除。

Deprecate the Nashorn JavaScript Engine

廢棄 Nashorn JavaScript 腳本引擎、API 和 jjs 工具。Nashorn 是在 JDK 8 中引入的，當(dāng)時(shí)完整實(shí)現(xiàn)了 ECMAScript-262 5.1。不過隨著 ECMAScript 的演進(jìn)加快，Nashorn 維護(hù)越來越困難。

Deprecate the Pack200 Tools and API

廢棄了 pack200 和 unpack200 工具，以及 java.util.jar 包中的 Pack200 API。

總結(jié)

G1 GC平均速度通過Java 8切換到 Java 11 就有 16％ 的改進(jìn)，但是大部分項(xiàng)目都用不到，一些高實(shí)時(shí)性的游戲可以用；

Java 11支持源文件直接運(yùn)行；

已完成項(xiàng)目不建議升級(jí)jdk11，或者新項(xiàng)目需要依賴現(xiàn)有代碼，不建議升級(jí)jdk11，因?yàn)樯?jí)版本涉及到大量的舊代碼移植，代碼重寫，架構(gòu)重構(gòu)，全量測(cè)試；

如果jdk8滿足開發(fā)需求,并且需依賴現(xiàn)有以JDK8開發(fā)的代碼，建議還是以jdk8進(jìn)行開發(fā)，否則如果選用jdk11可能面臨舊代碼重寫，架構(gòu)重構(gòu)，以及一些不知道的隱形依賴；

系統(tǒng)追求的是穩(wěn)定并非技術(shù)，jdk8已被廣泛驗(yàn)證非常穩(wěn)定，而且目前主流開發(fā)版本確實(shí)也是8，技術(shù)還是要服務(wù)于業(yè)務(wù)，穩(wěn)定大于一切；

從jdk8往上升級(jí)會(huì)出現(xiàn)一些jar依賴的改變，模塊化帶來的反射問題，classload的變化導(dǎo)致某些問題；

Spring，Spring Boot，Spring Cloud，Dubbo，Guava，Jackson，Tomcat，JUnit等等項(xiàng)目都適配了JDK11，并且經(jīng)歷了生產(chǎn)環(huán)境的檢驗(yàn)，才可以考慮是否將JDK8換成JDK11；

8之后，商用收費(fèi)

總結(jié)

以上是生活随笔為你收集整理的JDK8与JDK11的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。