發布的 Java11 將帶來 ZGC、Http Client 等重要特性，一共包含 17 個 JEP（JDK Enhancement Proposals，JDK 增強提案）。

    除了這些重要特性以外，Java 11 還有哪些值得關注的點呢？Java 現在更新那么頻繁，是否要考慮升級呢？工程師們還應該繼續學，學得動嗎？一起來看！
    不知不覺 JDK 11 已經發布了，從 9 開始，JDK 進入了讓人學不動的更新節奏，對于廣大 Java 工程師來說，真是又愛又恨，Java 演進快速意味著它仍將能夠保持企業核心技術平臺的地位，我們對 Java 的投入和飯碗是安全的，但同時也帶來了學習、選擇的困惑。
    所以，今天我們不準備做個流水賬的介紹，一起來看看工程師甚至是 IT 決策者關心的問題：
    JDK 更新如此頻繁，我是否要考慮升級? 新的發布模式下，企業的 IT 策略需要做出什么樣的調整？
    除了耍酷，JDK 11，或者說近的 JDK 版本，有什么真正值得生產環境中應用的特性？工程師要跟進嗎？
    對于個問題，本人十分確信 JDK 11 將是一個 企業不可忽視 的版本。

    首先，從時間節點來看，JDK 11 的發布正好處在 JDK 8 免費更新到期的前夕，同時 JDK 9、10 也陸續成為“歷史版本”，請看下面的 Oracle JDK 支持路線圖：

    JDK 更新很重要嗎？非常重要，在過去的很多年中，Oracle 和 OpenJDK 社區提供了接近免費的午餐，導致人們忽略了其背后的海量工作和價值，這其中包括但不僅僅限于：
    的安全更新，如，安全協議等基礎設施的升級和維護，安全漏洞的及時修補，這是 Java 成為企業核心設施的基礎之一。安全專家清楚，即使開發后臺服務，而不是前端可直接接觸，編程語言的安全性仍然是重中之重。
    大量的新特性、Bug 修復，例如，容器環境支持，GC 等基礎領域的增強。很多生產開發中的 Hack，其實升級 JDK 就能解決了。
    不斷改進的 JVM，提供接近零成本的性能優化…
    Easy is cheap”? Java 的進步雖然“容易”獲得，但莫忽略其價值，這得益于廠商和 OpenJDK 社區背后的默默付出。
    第二，JDK 11 是一個長期支持版本（LTS, Long-Term-Support）
    對于企業來說，選擇 11 將意味著長期的、可靠的、可預測的技術路線圖。有人說，那是對于付費訂閱客戶，不訂閱是不是就不用考慮 11 了呢？
    不，請放心，11 確定將得到 OpenJDK 社區的長期支持，目前 Oracle 提供了 OpenJDK build，雖然后續計劃未定，但是承諾“至少維護到明年”。即使是停止發布后續 JDK11 更新，Andrew Haley 等社區專家也已經明確保證，會組建并領導“JDK-11-updates”項目，并且保證：
    “please let me assure you of one thing: whether by Oracle orRed Hat or someone else, JDK LTS releases will continue to be supported. We all have a lot invested in Java, and we won't let itfall.”
    所以，LTS 版本將是企業 IT 決策者可以放心選擇的版本。
    回到第二個問題，我們一起來看看 JDK 11 的有哪些能力上的突破，能夠讓我們覺得升級到 JDK 11 是超值的。

    從 JVM GC 的角度，JDK 11 引入了兩種新的 GC，其中包括也許是劃時代意義的 ZGC，雖然其目前還是實驗特性，但是從能力上來看，這是 OpenJDK 的一個巨大突破，為特定生產環境的苛刻需求提供了一個可能的選擇。例如，對部分企業核心存儲等產品，如果能夠保證不超過 10ms 的 GC 暫停，可靠性會上一個大的臺階，這是過去我們進行 GC 調優幾乎做不到的，是能與不能的問題。相信你對下面的數據已經不再陌生。

    關于 ZGC 特性的解讀已經非常多，本文不再重復。我在這里主要介紹那些不起眼，但更具生產系統價值的部分。例如，對于 G1 GC，相比于 JDK 8，升級到 JDK 11 即可免費享受到：并行的 Full GC，快速的 CardTable 掃描，自適應的堆占用比例調整（IHOP），在并發標記階段的類型卸載等等。這些都是針對 G1 的不斷增強，其中串行 Full GC 等甚至是曾經被廣泛詬病的短板，你會發現 GC 配置和調優在 JDK11 中越來越方便。
    云計算時代的監控、診斷和 Profiling 能力，這是個人認為比 ZGC 更具生產實踐意義的特性。
    不知道你有沒有注意到，不知不覺中 Java 的應用場景發生了天翻地覆的變化，從單機長時間運行的 Java 應用，發展成為分布式、大的單體應用或小的 function、瞬時或長時間運行等，應用場景非常復雜。
    我們還用什么工具診斷 Java 應用？ JConsole，JProfiler，還是“自研”的各種工具？目前的工具大多是從對單個 Java 應用的診斷視角出發，試想如果我們的集群中有幾百、數千臺機器或容器，每臺機器有幾個或者幾十個 Java 進程，那么：怎么在不干擾生產系統的情況下，高效地跟蹤海量的 Java 進程，準確定位可以優化的性能空間？
    如何保證“隨機出現”的 JVM 問題，不需要進行額外的、令人頭痛的“重現”？
    JDK 11 悄悄地為我們提供了更加強大的基礎能力，主要是兩部分：
    JEP 328: Flight Recorder（JFR） 是 Oracle 剛剛開源的強大特性。我們知道在生產系統進行不同角度的 Profiling，有各種工具、框架，但是能力范圍、可靠性、開銷等，大都差強人意，要么能力不全面，要么開銷太大，甚至不可靠可能導致 Java 應用進程宕機。

    而 JFR 是一套集成進入 JDK、JVM 內部的事件機制框架，通過良好架構和設計的框架，硬件層面的優化，生產環境的廣泛驗證，它可以做到的可靠和低開銷。在 SPECjbb2015 等基準測試中，JFR 的性能開銷不超過 1%，所以，工程師可以基本沒有心理負擔地在大規模分布式的生產系統使用，這意味著，我們既可以隨時主動開啟 JFR 進行特定診斷，也可以讓系統長期運行 JFR，用以在復雜環境中進行“After-the-fact”分析。還需要苦惱重現隨機問題嗎？JFR 讓問題簡化了很多哦。

    在保證低開銷的基礎上，JFR 提供的能力也令人眼前一亮，例如：
    我們無需 BCI 就可以進行 Object Allocation Profiling，終于不用擔心 BTrace 之類把進程搞掛了。
    對鎖競爭、阻塞、延遲，JVM GC、SafePoint 等領域，進行非常細粒度分析。
    甚至深入 JIT Compiler 內部，全面把握熱點方法、內聯、逆優化等等。
    JFR 提供了標準的 Java、C++ 等擴展 API，可以與各種層面的應用進行定制、集成，為復雜的企業應用棧或者復雜的分布式應用，提供 All-in-One 解決方案。
    而這一切都是內建在 JDK 和 JVM 內部的，并不需要額外的依賴，開箱即用。
    另一方面，就是同樣不起眼的 JEP 331: Low-Overhead Heap Profiling。我們知道，高效地了解在 Java 堆上都進行了哪些對象分配，是診斷內存問題的基本出發點之一。 JEP 331 來源于 Google 等業界前沿廠商的一線實踐，通過獲取對象分配的 Call-site，為 JDK 補足了對象分配診斷方面的一些短板，工程師可以通過 JVMTI 使用這個能力增強自身的工具。
    從 Java 類庫發展的角度來看，JDK 11 的進步也是兩個方面：
    首先，是難得的現代 HTTP/2 Client API，Java 工程師終于可以擺脫老舊的 HttpURLConnection 了。新的 HTTP API 提供了對 HTTP/2 等業界前沿標準的支持，精簡而又友好的 API 接口，與主流開源 API（如，Apache HttpClient， Jetty， OkHttp 等）對等甚至更高的性能。與此同時它是 JDK 在 Reactive-Stream 方面的個生產實踐，廣泛使用了 Java Flow API 等，終于讓 Java 標準 HTTP 類庫在擴展能力等方面，滿足了現代互聯網的需求。
    第二，就是安全類庫、標準等方面的大范圍升級，其中特別是 JEP 332: Transport Layer Security (TLS) 1.3，除了在安全領域的重要價值，它還是中國安全專家范學雷所領導的 JDK 項目，完全不同于以往的修修補補，是個非常大規模的工程。
    除此之外，JDK 還在逐漸進行瘦身工作，或者償還 JVM、Java 規范等歷史欠賬，例如
    181: Nest-Based Access Control
    309: Dynamic Class-File Constants
    320: Remove the Java EE and CORBA Modules
    330: Launch Single-File Source-Code Programs
    335: Deprecate the Nashorn JavaScript Engine
    336: Deprecate the Pack200 Tools and API
    其中值得關注的是 JEP 335，它進一步明確了 Graal 很有可能將成為 JVM 向前演進的核心選擇，Java-on-Java 正在一步步的成為現實。
    JDK 11 還有什么遺憾嗎？很多 Valhalla、Loom、Panama 等項目中繼續補齊的短板，如協程、Value Type 等，目前還是可望而不可即，也許令人欣慰地是，我們能看到 Java 能夠正視自身存在的不足，不斷飛速發展。
    從 1995 年個版本發布到現在，Java 語言已經在跌宕起伏中走過了 23 年。這 23 年，既有 Java 連續霸榜多年的風頭無兩，也有近兩年 Java 不可忽視的頹勢。Java 是的語言嗎？不是，每個領域都有更合適的編程語言，沒有無所不能的存在。
    Java 語言到底有什么優勢可以占據排行榜的位置呢？
    其一，語法比較簡單，學過計算機編程的開發者都能快速上手，JVM也為開發者屏蔽了大量復雜的細節。
    其二，能力過硬，在若干個領域的競爭力都非常強，比如服務端編程，高性能網絡程序，企業軟件事務處理，大數據，分布式計算，移動、嵌入終端應用開發等等。重要的一點是其吸收了了業界的工程實踐，構建從嵌入式設備到超大規模軟件系統的能力，充分得到了實踐驗證。所有這些都使得 Java 成為企業軟件公司的，也得到很多互聯網公司的青睞。時移世易，Java 正在也必須改變。
    Java 改為每半年發版一次以后，在對合并關鍵特性、快速得到開發者反饋等方面，做得越來越好，我們明顯能夠看到各廠商和社區對 Java 投入的提高。發布的 JDK 11 雖然談不上劃時代的進步，但一定是 JDK 發展歷程中的一個重要版本，升級 JDK 就可以獲得的性能等各種提高，基礎能力的全面進步和突破，這一切無不說明，是時候開始評估并開始計劃升級到 JDK 11 了。