如何評價Java

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

標籤：Java

上一篇：Servlet和springMVC

下一篇：Java之大數加減乘除——構建類