1995 年，Sun Microsystem 公司發(fā)布了 Java 程序設計語言，為開發(fā)現代多媒體應用程序提供了一種更加可移植和交互的方式。從那時起，Java 便成為主流的編程語言之一，被應用于各行各業(yè)，也有著“一次編寫，到處運行”的優(yōu)勢特性。

近日，為揭曉 Java 生態(tài)系統(tǒng)的最新發(fā)展狀況，分析公司 New Relic 在調研了新版本、容器應用、垃圾回收等特性之后，最新發(fā)布了《2023 年 Java 生態(tài)系統(tǒng)現狀》報告。

在本文中，我們將與大家共同深入了解這門被廣泛應用的編程語言。

Java 17 的采用率在一年內增長了 430%

眾所周知，Java 版本分為長期支持（LTS）和短期支持支持版本。一般長期支持的版本都比較穩(wěn)定，或者官方會不斷更新補丁包。短期支持版本只是作為過渡版存在。

自 2017 年 Oracle 將 Java 版本的更新頻率更改為六個月一次時，長期支持 LTS 版本大概 2-3 年更新一次。不過，這種高頻的更新率讓無數網友怨聲載道，學不動的聲音不絕于耳，以至于很多人呈現出“你更任你更，我不用”的“擺爛”狀態(tài)。

這不，Oracle 在今年 3 月最新發(fā)布了 Java 20 版本。不過，據最新數據報告顯示，Java 11 已連續(xù)兩年位居榜首，成為開發(fā)者最常用的 Java 版本。

當下，超過 56% 的應用程序在生產中使用 Java 11，這一比例要高于 2022 年的 48% 和 2020 年的 11%。

Java 8 的使用率緊隨其后，近 33% 的應用程序在生產中使用它（低于 2022 年的 46%）。

雖然 Java 11 穩(wěn)居第一，但是最新的 LTS 版本 Java 17 的采用率逐年攀升，從去年不到 1% 的比例，迅速增長至今年的超過 9% 的占比。研究報告顯示，Java 17 在過去一年內增長率為 430%，而彼時 Java 11 花了數年時間才達到那個水平。

相較之下，只有 0.28% 的應用程序仍在生產中使用 Java 7。這并非沒有根由，究其原因，是因為官方對 Java 7 的支持已于 2022 年結束。大多數使用 Java 7 的應用程序都是尚未升級的遺留應用程序。

與 LTS 版本相比，短期的非 LTS Java 版本的使用率仍然極低，只有 1.6% 的應用程序使用非 LTS Java 版本（低于 2022 年的 2.7%）。

根據報告調研發(fā)現，可能導致影響非 LTS 版本使用率下降的一些因素包括：

• 缺乏支持

• 缺乏吸引力的新功能

• 距離下一個 LTS 版本發(fā)布的時間太短

曾幾何時，Java 8 發(fā)布了之后，外界并不能知曉下一個 LTS 版本 Java 11 會什么時候發(fā)布。不過，后來 ，Oracle 明確做出承諾：六個月一次更新，自此大家都有了清晰的認知，自然寧愿等等下一個 LTS 版本，也不愿在生產環(huán)境使用不穩(wěn)定的非 LTS 版本。

數據顯示，在使用的非 LTS Java 版本中，Java 14 仍然是最受歡迎的，占比0.57%（低于 2022 年的 0.95%），Java 15 緊隨其后（0.44%，低于 2022 年的 0.70%）。

亞馬遜現在是最受歡迎的 JDK 供應商

近年來，使用的 Java Developer Kit (JDK) 發(fā)行版的源代碼發(fā)生了變化。過去，很多開發(fā)人員常常從 Oracle 獲得他們的 JDK，但是 Oracle JDK 后來針對商業(yè)應用采取收費政策，這也讓很多人望而卻步，好在 OpenJDK 項目日漸豐富，成為眾人的選擇。

調查數據顯示，2020 年，Oracle 是最受歡迎的 JDK 供應商，約占 Java 市場的 75%。在其 JDK 11 發(fā)行版的許可更嚴格之后（在 Java 17 回歸更開放的立場之前），業(yè)界開發(fā)者開始逐漸遠離 Oracle。雖然 Oracle 在 2022 年以 34% 的份額保持榜首，但在 2023 年下滑至 28%。

與之形成鮮明對比的是，Amazon 的使用率急劇上升至 31% 的市場份額（從2020 年的 2.18% 和 2022 年的 22%），使其成為最受歡迎的 JDK 供應商。

容器化應用程序已成為主流，據 New Relic 調研顯示，70% 的 Java 應用來自容器。

容器會影響工程團隊分配計算和內存資源的方式。例如，New Relic 數據顯示，在容器中運行的應用程序少于 4core 的比例要高得多。

工程團隊正在擺脫容器中的單核設置，只有 36% 在使用（低于 2022 年的 42%），并轉向多核設置，超過 29% 使用 8core 設置（高于 2022 年的 20%）。

工程團隊通常在他們經常部署容器的云環(huán)境中使用較小的計算設置。但是，這種趨勢可能會給某些應用程序帶來意想不到的問題，這可能會導致配置減少。例如，如果團隊只使用一個 CPU，他們可能得不到他們期望的垃圾收集器——即使他們明確地設置了它。

自動垃圾收集是查看堆內存、識別哪些對象正在使用、哪些未使用以及刪除未使用對象的過程。 鑒于其在 JVM 性能中的核心作用，垃圾回收仍然是 Java 社區(qū)中的熱門話題。

New Relic 數據顯示，Garbage-First (G1) 垃圾收集器仍然是使用 Java 11 或更高版本的用戶的最愛，65% 的客戶使用它。G1 的主要好處之一是，它清除較小的區(qū)域而不是一次性清除大區(qū)域，從而優(yōu)化了收集過程。它還很少凍結執(zhí)行并且可以同時收集年輕代和老年代，這使它成為工程師的一個很好的默認設置。

其他在 Java 8 之后出現的實驗性垃圾收集器（ZGC 和 Shenandoah）在生產系統(tǒng)中的使用仍然很少。兩者都有生產就緒版本，但在一般處理中仍然可以忽略不計。

完整的報告內容詳見：https://newrelic.com/sites/default/files/2023-04/new-relic-2023-state-of-the-java-ecosystem-2023-04-20.pdf