Java已經誕生20多年了,依然是企業級開發中使用最廣泛的語言,也是挨罵最多的語言。Java廣受批評的四個缺點是:性能差、記憶體消耗大、GUI弱、代碼啰嗦,我們應該如何看待這幾個問題呢?在微服務的背景下,提倡圍繞業務能力而非技術來構建應用,允許由不同的語言構建應用程式。一個超大的集群,往往有上萬個微服... ...
1 語言優劣論
世上只有兩種編程語言:一種被人罵,一種沒人用。
Java已經誕生20多年了,依然是企業級開發中使用最廣泛的語言,也是挨罵最多的語言。技術圈經常有“A語言比B語言更好”的爭論,爭論的核心有兩點:語法和性能,比如“Java性能不如C#、Python語法比Java優雅”。
先談談語法的優劣。每個開發者都有自己偏愛的語法。你覺得很舒服的寫法,就有人覺得彆扭,這是個主觀問題。比如Java 8 中的Lambda表達式,可以極大的優化集合操作的代碼結構,但是不少人反感 () -> {} 這種符號,不願意在項目中使用。再舉個例子,Java語言定義變數的方式是數據類型前置、變數名後置,如: int maxSize = 100;而Go語言中變數名是前置的,如:var maxSize int = 100,寫慣了Java的人肯定不適應變數名前置。習慣的力量太大了,許多人將自己的偏愛當成評判的標準。
再談性能的優劣。編程語言的開發團隊固然希望性能更好,但是性能優化要一步一步來。我們要用發展的眼光看待性能問題,早期的Java編譯器和虛擬機性能確實堪憂,發展到如今已經改善了不少,以後也會繼續提升。如果一款語言性能真的差到無法接受,絕不會用於企業開發中。每種語言的使用場景不同,C語言的性能固然高於Java或者C#,為什麼沒有人C開發Web項目?在需求快速迭代的項目里,開發效率更重要,性能夠用就行,通俗的說就是人比機器貴。通常項目中遇到的大部分的性能瓶頸,降級需求或者優化設計方案就能解決,許多程式員的水平還沒有達到可以指責語言性能的程度。
企業選擇某款編程語言作為生產力工具,首先考慮的是人力招聘和培養的成本,其次才是語言特性和開發效率。這些年出現了許多新語言如Golang、Rust,也許概念更先進、性能更好,但是企業不會輕易在核心系統上採用新語言,以免出現不可預估的風險,保持系統的穩定才是最重要的。
2 Java的爭議
1995 年 5 月 23 日,Java 正式發佈。經過20多年的發展,Java孕育出了大量的開源組件和開發者。在它誕生的年代,相比其他語言有五個優勢:
(1)簡單易學:沒有指針操作和手動記憶體分配,易學易用,程式員心智負擔較小。
(2)面向對象:僅支持面向對象編程,單一的編程範式可以避免工程過度複雜。
(3)網路編程:提供了更簡單的網路編程庫,適合構建大型的網路分散式系統。
(4)反射機制:通過反射機制增強了語言的動態性,大部分開發框架都用到了這個特性。
(5)跨平臺:通過JVM屏蔽了底層硬體的差異性,為上層應用提供統一的介面。應用程式被編譯成與電腦結構無關的位元組碼,可以運行在不同的操作系統中。
事物總是有兩面性,為瞭解決一個問題引入一個特性,也必然帶來新的問題。我們應該如何辯證的看待Java廣受詬病的幾個問題呢?
- 性能差
通常有GC語言不提供非常底層的記憶體操作方法,因此不可能達到無GC語言的性能,而且當虛擬機徹底回收垃圾時,應用程式會被強制停止,某些需要低延遲的場景絕不能接受這種狀態。事實上,如果進行數值計算的基準測試,Java比 C++沒有慢多少,企業開發中的Java項目速度慢的根本原因是框架濫用反射,載入反射代碼要比普通程式慢幾十倍,編譯器沒法優化反射代碼。在資源緊張或者高性能場景下,C / C++仍然是首選,Java無法勝任。
- 記憶體占用大
Java應用程式啟動後包含JVM實例,一個“Hello World”都要消耗幾十兆記憶體。每個Java的對象都要包含一個96 bits的對象頭,一個32bits的integer就要占用記憶體96bits+32bits=128bits。向Go這種面向值的語言,每個值的存儲消耗最低僅為2bits。企業級框架Spring大量採用HashMap緩存數據,也是極度消耗記憶體的。
- GUI弱
Java桌面軟體的性能低、開發體驗也差。最新的GUI庫JavaFX比Swing、AWT進步很多,但是遠遠不如Qt(C++)、WinForm / WPF (C#) 等框架。從商業角度考慮,多數企業軟體並不需要跨平臺,運行在Winows就足夠了,少量的要相容MacOS,Java跨平臺特性在這種情況下反而是雞肋。谷歌選擇Java語言開發Android應用,看重的是龐大的Java生態,而不是語言特性。
- 代碼啰嗦
Java僅支持面向對象編程範式,書寫起來極為啰嗦,比如main方法不能是一個獨立的函數,必須放在沒有實際意義的class中。好處是風格統一,壞處就是死板和啰嗦。採用Spring框架開發的Java項目,只要遵循基本的代碼規範,每個人寫出來的都差不多,可讀行不會太差。與之相反,C++這種多範式語言,非結構化、結構化、面向對象、巨集、模板等等應有盡有,靈活性極大,要精通也很難。維護一個大型的C++項目,就像在讀一本百科全書。
3 雲原生的考驗
雲計算是一種實施模式,是指通過互聯網方式交付存儲、伺服器、應用等等。“雲”是一種管理 IT 資源的方法,能夠取代本地設備和私有數據中心。在雲計算模式下,用戶無需購買和維護大量的計算、存儲和其他 IT 基礎設施,直接訪問雲計算提供商的計算、網路和存儲資源即可。雲服務提供商能夠保障物理設備的正常運轉、資源的按需調配等等。
雲原生是一種構建和運行應用程式的方法,是一套技術體系和方法論。雲原生是Cloud+Native的組合詞,Cloud表示應用程式位於雲中,而不是傳統的數據中心;Native表示應用程式從設計之初即考慮到雲的環境,原生為雲計算而設計,可以充分發揮雲計算平臺的彈性和分散式優勢。雲原生架構有4個重要的實施原則:
(1)DevOps:採用自動化工具將應用快速部署到生成環境,並且讓開發、運維互相協作。
(2)持續交付:支持頻繁持續的發佈應用,快速反饋部署故障,有效降低發佈風險。
(3)微服務:將龐大複雜的單體服務拆分為更小的微服務,每個微服服可以快速、獨立的部署。
(4)容器化:將應用程式及依賴項打包成鏡像,以容器化的方式快速分發。
在虛擬化技術沒有廣泛應用的階段,部署應用程式是個繁瑣的事情。為了讓程式在Linux、Windows等平臺以及x86、AMD64、SPARC、MIPS、ARM等指令集架構上都能正常運行,必須先將源碼編譯為對應的可執行文件,或者直接分發源代碼,由使用者自行構建可執行文件。Java發佈時,提出了一句動人的口號:一次編寫,到處運行”(Write Once, Run Anywhere),解決了應用部署的痛點。在雲原生架構下,Java以及JVM的特性面臨了新的挑戰。
在微服務的背景下,圍繞業務能力而非技術來構建應用,允許由不同的語言構建應用程式。一個大型的微服務集群,往往有成千上萬個容器在運行。為了更有效率的管理容器,對微服務有幾個訴求:鏡像體積小、記憶體消耗少、啟動速度快,這些卻都是Java的弱項。再小的Java程式也帶著完整的虛擬機和標準類庫,這樣會降低拉取鏡像和創建容器的效率;Java的程式都會有固定的基本記憶體開銷和啟動時間,開源框架Spring等廣泛採用的依賴註入也使得容器的啟動時間過長。最好解決方案是,將Java源碼直接編譯為二進位可執行文件,再將可執行文件打包為鏡像。
GraalVM是Oracle實驗室推出的基於Java開發的開源高性能多語言運行時平臺,它既可以在傳統的 OpenJDK 上運行,也可以通過 AOT(Ahead-Of-Time)編譯成可執行文件單獨運行。GraalVM將源代碼打包成可執行代碼,運行時不包含JRE,實現秒級別的啟動,占用記憶體更小。
知名開源框架 Spring 的研發團隊也發佈了 Spring Native 項目,利用 GraalVM 將 Spring 應用生成可執行的原生鏡像(Native Image)。這些原生鏡像的啟動速度極快、記憶體消耗也更少,但是比JVM的構建時間更長、運行時優化也不足。目前 Spring Navtive 仍然處於孵化階段,國內公司用於生產環境的很少。
參考
https://www.cnblogs.com/JaxYoun/p/16483067.html
https://zhuanlan.zhihu.com/p/333926379
https://zhuanlan.zhihu.com/p/150190166
https://www.codingbrick.com/archives/1130.html
公 眾 號:編碼磚家
獨立博客:codingbrick.com
文章出處:https://www.cnblogs.com/xiaoyangjia/p/17256055.html
本文版權歸作者所有,任何人或團體、機構全部轉載或者部分轉載、摘錄,請在文章明顯位置註明作者和原文鏈接。