我們先來看下大家都在使用的 Java 版本（包括 JVM 語言：Kotlin、Groovy、Scala）：

從結果我們可以看到，Java8 占比 37%，Java11 占比 29%，甚至有 12%的被調查者使用了高于 Java12 的版本。

Java8 是 2014 年發布，相較于之前版本，增加了 Lambda 表達式、Stream 流式處理等一種優秀的 API。至今已 8 年時間，Java 版本也是從 8 一直升到了 17。版本號一直在增加，卻沒有增加特別吸引人的語言特性。

哪些因素是大家升級的動力呢？

可以看到，主要的升級因素包括 LTS 版本（25%）、安全性（23%）、性能（20%），新特性（18%）和隨大流（14%）占比低一些。

從這點我們也就知道為什么 Java11 之后的版本占比并不高了，隨著 Java17 的發布，可能 Java8 和 Java11 的占比會降低。安全性方面，除非是嚴重的漏洞，一般 Java 開發團隊會通過補丁的方式升級，不會影響大版本號占比。

性能方面，Java 團隊一直在不斷優化，隨著 G1、ZGC、Shenandoah 等一眾優秀的 GC 被添加進來，這也成為大家從 Java8 升級的重要原因。

就功能特性而言，Java11 之后增加了 Record 類型、密封類、instanceof 模式匹配、Swtich 表達式和模式匹配等一些語法糖。這些新特性，也能夠提升升級到 Java17 的意愿。

Java17 是 2021 年下半年發布的 LTS 版本（長期支持版）。

我們看下大家升級的意愿：

從結果可以看出來，有 37%的人會在未來 6 個月內升級，有 25%的人會在 6-12 個月內升級，不會升級的占比僅占 8%。

可見，有 62%的人會在未來一年內升級到 Java17，大家的升級意愿還是比較強的。

我們都知道，市面上有很多的 JDK 版本，在 Oracle 起訴 Google 侵權之前，非企業特供的情況下，我們基本上用的都是 OracleJDK，后來因為容器中使用 JDK 版本的版權問題，容器中大部分使用了 OpenJDK。

從問卷結果也反映了這種情況：

OracleJDK 的版本占比 36%，OpenJDK 的版本占比 43%，其中包括標準 OpenJDK 和 AdoptOpenJDK 版本。

有些同學會疑惑 OracleJDK 和 OpenJDK 的區別在哪？我們日常用到的部分，沒有任何區別。

這個問題的結果有些出乎我的預料：

各種架構風格中，微服務架構僅占 32%，單體架構占比 22%，模塊化單體架構占比 13%，SOA 架構占比 12%。

從結果來看，這個問卷的對架構風格的定義和分類比較細膩。

很多公司把系統的服務化、模塊化也統稱為了微服務，這是一種很嚴重的錯誤，在之前的文章 《微服務架構的陷阱：從單體到分布式單體》 中介紹過這種錯誤。

推薦閱讀：

• 《什么是微服務？》
• 《微服務編程范式》
• 《從單體架構到微服務架構》。

這里不對架構風格做出評價，架構只有合適與否，沒有優劣之分。

既然微服務架構占比高一些，我們就來看一下微服務架構的應用趨勢。

從結果來看，有 44%的人團隊已經是完全微服務架構了，還有 44%的團隊在向微服務架構遷移。可見，在 Java 行業中，微服務架構是得到大家普遍認可的。

但是這個結果與上面的架構風格占比結果有出入，可能是問卷題目設計問題，或者問題回答者的主觀原因，不能夠苛求結果準確性。

既然是微服務架構，每個應用中服務數量必然超過 1 個。從結果可以看出來，有 54%的應用中少于 10 個服務，還有 22%的應用服務數量超過 20 個。

按照公司規模維度，越是大公司，每個應用中服務數量越多，結果符合康威定律的。從大家普遍實踐結果看，當團隊規模較小時，要盡量減少微服務數量。市面上很多老師會告訴我們，微服務架構要按照業務域拆分，但是你要知道，如果團隊規模不大，即使拆分了業務域，可能最終開發調試維護也只有你一個。

從結果看，SpringBoot 幾乎霸占了整個微服務市場。所以，大家在日常工作學習過程中，還是主要看看 SpringBoot 棧吧。

在國內，SpringBoot 技術棧還會細分為 SpringNetflixCloud 棧、SpringAlibabaCloud 棧、SpringBoot+Dubbo 棧等。

不同的技術棧中組件有些差異，所以我們需要掌握的不是簡單的應用，還要了解其中的原理。原理掌握了，不同的組價只是在應用層面的差異。

隨著公司業務的增長，應用中會增加各種各樣的新功能。問卷中有個問題是關于隨著時間推移，微服務啟動時間的變化：

可見，有 60%的服務啟動時間都在增加，甚至有 13%的應用啟動時間增長超過 50%，有 30%的應用啟動時間增長范圍在 10%-50%。

為什么啟動時間會增長呢？這個與公司業務增長后，代碼增加了很多新功能有關。隨著功能增加、類的增加，系統體積增大、加載類數量增大，啟動時間會隨之增加。這會引起系統的腐化，當腐化到一定程度，可能就需要重構了。或者隨著業務增長，原來的微服務邊界劃分不合適了，需要重新劃分系統邊界，拆分微服務。

既然微服務總體的啟動時間在增長，那啟動時間一般是多久呢？

可以看到，只有 9%的服務在 1 分鐘內啟動成功，有 26%的服務啟動時間需要 10 分鐘以上。

從上圖可以看出來，人員規模大于 100 人的公司中，服務啟動時間普遍長于少于 100 人的公司。產生這種情況的原因有這么幾個：

1. 公司規模大一些，可能業務復雜一些，服務中的代碼、類庫更多一些；
2. 公司規模大一些，依賴的組件更多一些，在服務啟動時，需要與各種中間件建立鏈接，然后彼此交換成功心跳，自然需要時間更多。

采用微服務其中一個好處是服務足夠小，啟動時間比較少。但是，從上面兩個問卷結果來看，普遍情況是啟動時間比較長，而且在變得更長。

從問卷結果可以看到，Docker 使用率是 41%，Kubernetes 使用率是 26%，VMware 使用率是 16%，Vagrant 使用率是 3%，即有 86%已經實現了虛擬化，其中 Docker、Kubernetes 占比最高。

所以在 Java 升級版本特性中，實現了容器感知的能力，使 Java 服務容器化更容易一些。

JRebel 的這個問卷調查是全球性質的，從全球范圍看，AWS 當之無愧的 NO.1。AWS 作為亞馬遜曾經的附屬產業，已經成為了亞馬遜的重要業務之一。

與亞馬遜的經歷類似，阿里巴巴從電商切入，然后布局云服務（阿里云）。如果還是走亞馬遜的老路，勢必沒法超越。不過阿里從很多年前開始布局 CPU 和芯片領域，如果能夠有所突破，就可以破開西方技術的封鎖，依托我國的發展潛力，未必不能撼動亞馬遜的 PaaS 服務商地位。

前面關于微服務的問題中，SpringBoot 是眾多微服務框架中的首選，SpringBoot 默認的應用容器是 Tomcat。加之 Tomcat 的開源方式，將近半數應用服務器選擇 Tomcat 也是預料之中。

Maven 和 Gradle 到底該用哪個？這個問題似乎爭論許久。從問卷結果看，Maven 占有率是 68%，Gradle 占有率是 23%，Maven 還是有絕對的優勢。

Gradle 采用了約定大于配置的方式，與 SpringBoot 的理念一致。但是從市場接受度和發展而言，并沒有形成替換 Maven 的風潮。Android 項目默認使用 Gradle，能夠看出 Google 對 Gradle 的推崇，也從側面印證 Gradle 的優秀。但是，Gradle 并沒有絕對優勢。

我是從 2015 年開始使用 IntelliJ IDEA，試用之后立馬拋棄了 Eclipse。首先是快捷鍵的設計，可以很大程度擺脫鼠標。內置的插件市場，可以找到任何需要的插件，提升編程體驗。更關鍵的是，JetBrains 公司出品的 IDE，可以無縫對接，實現不同語言的編程支持。

Eclips 也不是一無是處，它的插件體系也是相當豐富，很多低代碼開發工具都是基于 Eclipse 開發的。如果是普通開發，推薦使用 IntelliJ IDEA；如果想要做低代碼工具，可以考慮對 Eclipse 進行二次開發。

這一部分屬于 JRebel 有私心的部分，JRebel 一個優勢功能是提供熱部署能力，所以會在問卷中詢問被調查者重新部署應用的時間。

很多時候，我們可能只改動一行代碼，然后驗證功能是不是正常，這個時候需要重新部署應用。JRebel 統計了重新部署需要花費的時間。

從結果上看，重新部署需要超過 3 分鐘時間的占 50%，其中 21%的比率需要 10 分鐘以上。那這段時間，大家會干什么？

有 28%會增加新功能；有 20%會優化系統性能；有 19%會完善測試覆蓋。這些都是正向的，大概率的是那些回答其他的：喝咖啡、喝啤酒、開趴、睡覺、釣魚……

不過也是符合我們工作的原因：我們工作是為了生活，而不是為了加班。所以，假如每天給你 1 小時的自由時間，你會用來做什么呢？歡迎評論區討論。

1. 微服務的使用情況來看，啟動時間和重新部署時間不是優先考慮的因素。多數選擇微服務架構的原因無非有兩個：
   1. 看中微服務架構流行趨勢，聽說這個很好，那就開始用，至于是微服務架構還是分布式單體架構，就不重要了；
   2. 微服務的優勢能夠彌補帶來的弊端，比如業務迭代速度等；
2. 微服務收康威定律影響比較大；
3. 技術在不斷革新，但是大家會比較理性地接受。公司規模越大，越趨于選擇成熟的技術；
4. 容器已經是大勢，需要掌握。

技術不斷發展，我們需要學習的東西越來越多，很多時候感覺學不動了。但既然選擇了這個行業，拿著高于其他行業的薪資，也承擔著各種裁員的風險，總歸是要有一些技能傍身，才不至于被歷史的車輪碾成粉末。

青山不改，綠水長流，我們下次見。

• https://www.i-programmer.info/news/80-java/15317-wheres-java-going-in-2022.html
• https://www.jrebel.com/resources/java-developer-productivity-report-2022

• 一文掌握 Java8 Stream 中 Collectors 的 24 個操作
• 一文掌握 Java8 的 Optional 的 6 種操作
• 使用 Lambda 表達式實現超強的排序功能
• Java8 的時間庫（1）：介紹 Java8 中的時間類及常用 API
• Java8 的時間庫（2）：Date 與 LocalDate 或 LocalDateTime 互相轉換
• Java8 的時間庫（3）：開始使用 Java8 中的時間類
• Java8 的時間庫（4）：檢查日期字符串是否合法
• Java8 的新特性
• Java9 的新特性
• Java10 的新特性
• Java11 中基于嵌套關系的訪問控制優化
• Java11 的新特性
• Java12 的新特性
• Java13 的新特性
• Java14 的新特性
• Java15 的新特性
• Java16 的新特性
• Java17 的新特性
• 從小工到專家的 Java 進階之旅

你好，我是看山。游于碼界，戲享人生。如果文章對您有幫助，請點贊、收藏、關注。我還整理了一些精品學習資料，關注公眾號「看山的小屋」，回復“資料”即可獲得。

個人主頁：https://www.howardliu.cn
個人博文：2022 年 Java 行業分析報告
CSDN 主頁：https://kanshan.blog.csdn.net/
CSDN 博文：2022 年 Java 行業分析報告

---------------------
作者：看山
來源：CSDN
原文：https://blog.csdn.net/liuxinghao/article/details/125356270
版權聲明：本文為作者原創文章，轉載請附上博文鏈接！
內容解析By：CSDN,CNBLOG博客文章一鍵轉載插件