Java正青春：現(xiàn)狀與技術(shù)趨勢(shì)報(bào)告
發(fā)布時(shí)間：2021-08-03 09:57:28 已幫助：97人
背景
1991年，James Gosling帶領(lǐng)團(tuán)隊(duì)開(kāi)始了一個(gè)叫"Oak"的項(xiàng)目，這個(gè)就是Java的前身。1995年，Java1.0發(fā)布。“Write once,run anywhere"這句Java口號(hào)想必大家耳熟能詳。Java剛開(kāi)始出現(xiàn)的時(shí)候主要面向Interactive Television領(lǐng)域，直至后來(lái)幾年的發(fā)展，當(dāng)時(shí)的SUN（后來(lái)在2010年被Oracle收購(gòu)）一度想用Java來(lái)打造桌面的網(wǎng)絡(luò)操作系統(tǒng)，取代當(dāng)時(shí)如日中天的Windows。不過(guò)Java后來(lái)的發(fā)展，不曾想雖未在桌面領(lǐng)域內(nèi)取得多大的建樹(shù)，出乎意料地，卻在企業(yè)級(jí)應(yīng)用領(lǐng)域開(kāi)花結(jié)果，占據(jù)了如今幾乎統(tǒng)治的地位。失之東隅，卻收之桑榆。
JavaSE開(kāi)源現(xiàn)狀
Sun在2006年的Java One大會(huì)上，宣布Java技術(shù)開(kāi)源，隨后2006年底在GPL協(xié)議下發(fā)布HotSpot以及javac，這是Java發(fā)展中的里程碑事件。阿里巴巴最早在2012簽署OCA，并參與到了OpenJDK的開(kāi)發(fā)。
圖片
OpenJDK是JavaSE開(kāi)源的Reference Implementation。在JavaOne 2017的Keynote上(2018年JavaOne被Oracle重命名為CodeOne)，Oracle承諾將開(kāi)源所有的OracleJDK里包含的商業(yè)實(shí)現(xiàn)功能[1]。
圖片
在2018年發(fā)布的Java11，Oracle已經(jīng)讓OpenJDK和Oracle JDK兩者的二進(jìn)制文件在功能上盡可能相互接近，盡管OpenJDK與OracleJDK兩者在一些選項(xiàng)之間仍然存在一些差異[2]。
另外，除了OpenJDK這條主線，在最近的幾年里，Java基礎(chǔ)技術(shù)的開(kāi)源有愈演愈烈趨勢(shì)：2017年，IBM將內(nèi)部使用20多年之久的J9虛擬機(jī)開(kāi)源，并貢獻(xiàn)到Eclipse Foundation，而隨后2018年，Oracle開(kāi)源GraalVM 1.0，其核心包含用Java寫的Just-in-Time compiler/Graal,SubstrateVM以及支持多語(yǔ)言解釋器的Truffle框架。各個(gè)企業(yè)開(kāi)源的主要?jiǎng)訖C(jī)，想通過(guò)開(kāi)源構(gòu)建并受益于一個(gè)更為強(qiáng)大的語(yǔ)言生態(tài)系統(tǒng)。
云+開(kāi)源結(jié)合在一起，使得普通開(kāi)發(fā)者以較低的門檻獲得工具(鏈)的使用和體驗(yàn)，任何一家企業(yè)都可以像任何大型組織一樣，使用的相同技術(shù)(democratizing)，這是開(kāi)發(fā)者的黃金時(shí)代。
Java is Still Free:你該選擇什么樣的JDK？
Java仍然免費(fèi)，但隨著OracleJDK License變化開(kāi)始轉(zhuǎn)向收費(fèi)，OpenJDK會(huì)逐漸取代OracleJDK成為市場(chǎng)主流，這點(diǎn)也可以從JVM 2020生態(tài)報(bào)告中看出趨勢(shì)：OracleJDK從前一年的70%的開(kāi)發(fā)者選擇使用率降到2020年的34%。
OracleJDK收費(fèi)，在客觀上也加劇了OpenJDK生態(tài)的碎片化趨勢(shì)，出現(xiàn)了包括Alibaba Dragonwell在內(nèi)的多個(gè)基于OpenJDK的可選實(shí)現(xiàn)。
企業(yè)在選擇使用那個(gè)Java Vendor的JDK版本時(shí)，幾個(gè)方面的考慮因素可以參考：
安全與穩(wěn)定：是否會(huì)及時(shí)同步上游的最新更新，包括安全補(bǔ)丁，關(guān)鍵的問(wèn)題修復(fù)等。
JavaSE標(biāo)準(zhǔn)兼容：是否與標(biāo)準(zhǔn)Java兼容。
性能與效率：是否可以在問(wèn)題診斷，性能調(diào)優(yōu)方面提供有效的工具支持，幫助一線的開(kāi)發(fā)同學(xué)高效地解決Java問(wèn)題。在JVM，到JDK(Class library)層面，是否有面向企業(yè)業(yè)務(wù)場(chǎng)景的優(yōu)化特性，可以幫助提升資源的利用率，生產(chǎn)系統(tǒng)的穩(wěn)定性等等。
快速的新技術(shù)采納：伴隨收費(fèi)，Oracle管理Java版本生命周期采用了Long Term Support(LTS)的概念，Oracle每三年會(huì)指定一個(gè)LTS的Java版本，Java 8/11都是LTS版本。大部分企業(yè)，尤其是大中型企業(yè)很難跟上Java每六個(gè)月一發(fā)布的節(jié)奏，像Java 12，13這樣的Feature Release(FR)版本。那么問(wèn)題來(lái)了，如果你選擇Stay在LTS版本上，比如Java 11，在新版本(Java11+)發(fā)布的JVM/JDK技術(shù)，是否可以在不升級(jí)的情況下，提前享受這些技術(shù)紅利？
這里分享下Alibaba Dragonwell在這些方面的計(jì)劃與思考。
Alibaba Dragonwell是阿里巴巴內(nèi)部廣泛使用的AJDK(AlibabaJDK)的開(kāi)源版本，Alibaba Dragonwell作為基石，支撐了阿里經(jīng)濟(jì)體內(nèi)幾乎所有的Java業(yè)務(wù)，經(jīng)過(guò)了雙11等大促的考驗(yàn)。Alibaba Dragonwell主要針對(duì)的場(chǎng)景是數(shù)據(jù)中心大規(guī)模Java應(yīng)用部署情況下，Java應(yīng)用穩(wěn)定性、效率以及性能的優(yōu)化與提高。
2019年3月阿里開(kāi)源Alibaba Dragonwll 8.0.0，我們也一直正在踐行開(kāi)源時(shí)候的承諾，AJDK內(nèi)部使用的特性在逐步開(kāi)源。到剛剛發(fā)布Alibaba Dragonwell 8.3.3，我們已經(jīng)開(kāi)源了JWarmup，ElasticHeap，多租戶，JFR等眾多功能，協(xié)程Wisp 2.0，GCIH等也在開(kāi)源的規(guī)劃上。
圖片
同時(shí)，Alibaba Dragonwell作為OpenJDK的下游，每個(gè)發(fā)行版都會(huì)同步上游最新更新，包括安全更新，問(wèn)題修復(fù)等，并經(jīng)過(guò)阿里內(nèi)部大規(guī)模的應(yīng)用集群測(cè)試。
在新技術(shù)Adoption方面，Alibaba Dragonwell目前發(fā)布和維護(hù)了Java 8,11兩個(gè)LTS版本，阿里JVM團(tuán)隊(duì)會(huì)根據(jù)實(shí)際業(yè)務(wù)狀況，移植Java11+的相關(guān)功能到Java 8和11兩個(gè)版本，這樣Alibaba Dragonwell用戶可以在不跟進(jìn)Java 12,13等這些FR版本的情況下，提前享受這些功能帶來(lái)的技術(shù)紅利。
OpenJDK技術(shù)趨勢(shì)
縱觀Java技術(shù)20多年的發(fā)展，始終圍繞著兩大主題：Productivity以及Performance。在很多情況下，Java在設(shè)計(jì)上Productivity是優(yōu)于Performance考慮的。Java引入的Garbage Collector把程序員從復(fù)雜的內(nèi)存管理中解脫出來(lái)，但在另一方面Java應(yīng)用始終困擾于GC暫停時(shí)間的影響。Java基于棧式虛擬機(jī)的中間字節(jié)碼設(shè)計(jì)，很好地抽象了不同平臺(tái)(Intel,ARM等)的差異性，同時(shí)通過(guò)Just-in-Time(JIT)編譯技術(shù)，解決的Java應(yīng)用peak性能,但在另一方面JIT不可避免引入了Warmup的代價(jià)，正常情況下Java程序永遠(yuǎn)需要先load class，解釋執(zhí)行，然后再到高度優(yōu)化的代碼執(zhí)行。
如果從JVM視角來(lái)總結(jié)梳理下目前OpenJDK社區(qū)正在發(fā)生，孵化的相關(guān)技術(shù)，主要從工具，GC，編譯器，以及Runtime四個(gè)方面進(jìn)行一個(gè)主要概括：
圖片
JFR/JMC
Oracle從Java 11開(kāi)源了其之前一直作為商業(yè)功能的JFR，JFR是功能強(qiáng)大的Java應(yīng)用問(wèn)題診斷與性能剖析工具。阿里巴巴也是作為主要的貢獻(xiàn)者，與社區(qū)包括RedHat等，一起將JFR移植到了OpenJDK 8，預(yù)計(jì)2020年7月即將發(fā)布的OpenJDK 8u262(Java8)將會(huì)默認(rèn)帶有JFR功能，這樣Java 8的用戶可以基于這個(gè)版本免費(fèi)使用JFR功能。
ZGC/Shandoath
無(wú)論是Oracle在Java 11發(fā)布的ZGC，還是RedHat已經(jīng)做了好幾年的Shandoath，都實(shí)現(xiàn)了concurrent copy GC，解決Large Heap情況下的GC停機(jī)性能。ZGC最新?tīng)顟B(tài)，在9月份即將發(fā)布的JDK 15，ZGC將從Experimental功能變?yōu)樯a(chǎn)可用[3]。實(shí)際上，在AJDK 11上，阿里巴巴團(tuán)隊(duì)JVM團(tuán)隊(duì)已經(jīng)做了大量Java 11+到Java 11的ZGC移植工作，以及相關(guān)問(wèn)題修復(fù)，2019年雙11和阿里數(shù)據(jù)庫(kù)團(tuán)隊(duì)一起，讓數(shù)據(jù)庫(kù)應(yīng)用運(yùn)行在ZGC上，100+GB Heap情況下GC暫停時(shí)間可以保持在<10ms以內(nèi)，詳細(xì)討論參考[4]。
Graal
用Java開(kāi)發(fā)的新一代Just-in-Time編譯技術(shù)，用來(lái)替代目前HostSot JVM的C1/C2編譯器，OpenJDK上的Ahead-of-Time(AOT)技術(shù)也是基于Graal編譯器開(kāi)發(fā)。
Loom
OpenJDK社區(qū)協(xié)程項(xiàng)目，對(duì)應(yīng)于AJDK的Wisp 2.0實(shí)現(xiàn)，詳細(xì)討論可以參考[5]。
進(jìn)擊的Java：面向未來(lái)演進(jìn)
2020，站在一個(gè)全新的節(jié)點(diǎn)上，本文也從三個(gè)大的方面Cloud Native，AI，以及多語(yǔ)言生態(tài)三個(gè)方面展望下未來(lái)的發(fā)展，有些討論本身是超越Java本身的。
面向Cloud Native的語(yǔ)言進(jìn)化
云原生時(shí)代，軟件的交付方式發(fā)生的根本性變化。以Java為例，在之前Java開(kāi)發(fā)者交付的是應(yīng)用本身，具體體現(xiàn)在以"jar","war"的形式交付,而云原生則是以Container為交付單位的：
圖片
在運(yùn)行方面，面向Cloud Native的應(yīng)用要求：
Reactive
Always Watching
Extreme low memory footprint
Quick boot time
Java語(yǔ)言作為企業(yè)計(jì)算，互聯(lián)網(wǎng)領(lǐng)域的王者，擁有一致性，豐富的構(gòu)建在Java語(yǔ)言之上的生態(tài)系統(tǒng)，豐富的三方庫(kù)，多樣的Serviceability支持等，隨著云時(shí)代應(yīng)用微服務(wù)化，Serverless，這些新的架構(gòu)逐漸觸及到了Java程序速度提升的天花板——Java自身的啟動(dòng)運(yùn)行開(kāi)銷。
在Cloud Native這個(gè)新的上下文里，我們談?wù)撜Z(yǔ)言的進(jìn)化，絕不僅僅限于運(yùn)行時(shí)，編譯器層面，新的計(jì)算形態(tài)一定伴隨著編程模型的變革，這涉及圍繞程序語(yǔ)言的Library，F(xiàn)ramework，Tools等一系列配套的改革。從目前業(yè)界來(lái)看，也有不少的項(xiàng)目正在發(fā)生：配合GraalVM/SVM(Java靜態(tài)編譯技術(shù))的下一代編程框架Quarkus,Micronaut,以及Helidon，Quarkus更是提出了“container first”，他們提倡的分層的lightweight uber-jar的概念正是符合了container交付這一趨勢(shì)。而Red Hat的Java團(tuán)隊(duì)與OS團(tuán)隊(duì)合作的"Checkpoint Restore Fast Start-up"技術(shù)(AZul在JVM技術(shù)峰會(huì)'2019上也提出過(guò)類似的想法)則是在更加底層的技術(shù)棧上解決Java快速拉起問(wèn)題。
在Java for Cloud Native方向，我們也開(kāi)展了相關(guān)研發(fā)工作。Java是靜態(tài)語(yǔ)言，但是包含了大量的動(dòng)態(tài)特性，包括反射，Class Loading，Bytecode Instrument(BCI)等等，這些動(dòng)態(tài)特性本質(zhì)上都是違反GraalVM/SVM所要求的Closed-World Assumption(CWA)原則，這也是導(dǎo)致傳統(tǒng)跑在JVM的Java應(yīng)用不容易在SVM編譯運(yùn)行的主要原因。阿里巴巴JVM團(tuán)隊(duì)對(duì)AJDK做了靜態(tài)化裁剪，務(wù)求在Java靜/動(dòng)態(tài)特性之間找到一個(gè)確定的邊界，從JDK的層面為Java靜態(tài)編譯提供可能性。同時(shí)向上，與螞蟻中間團(tuán)隊(duì)合作，定義面向靜態(tài)編譯的Java編程模型，通過(guò)編程框架來(lái)約束-Java應(yīng)用的開(kāi)發(fā)是面向靜態(tài)編譯友好的。我們靜態(tài)編譯了基于螞蟻開(kāi)源中間件SOFAStack構(gòu)建的服務(wù)注冊(cè)中心Meta節(jié)點(diǎn)應(yīng)用，相較于傳統(tǒng)的運(yùn)行在JVM上，性能有量級(jí)的提升：服務(wù)啟動(dòng)時(shí)間降低了17倍，可執(zhí)行文件大小降低了3.4倍，運(yùn)行時(shí)內(nèi)存降低了一半。詳見(jiàn)[6]。
AI的興起，編程語(yǔ)言異構(gòu)計(jì)算的新挑戰(zhàn)
2005年，時(shí)任Intel CTO的Justin Rattner，說(shuō)過(guò)“We are at the cusp of a transition to multicore,multithreaded architectures”，在前后的十幾年中，編程語(yǔ)言與編譯器領(lǐng)域一直在努力面向parallel architectural paradigm做優(yōu)化探索。隨著AI這些年的興起，不同的時(shí)間節(jié)點(diǎn)，相似的場(chǎng)景，面向FPGA/GPU異構(gòu)計(jì)算場(chǎng)景，對(duì)編程語(yǔ)言與編譯器領(lǐng)域提出了新的挑戰(zhàn)。
除了傳統(tǒng)Compiler諸如IBM XL Compilers,Intel Compilers等做的Automatic Parallelizing工作，在極致性能探索方面，基于多面體模型(polytope model)的編譯優(yōu)化技術(shù)作為解決程序并行化、數(shù)據(jù)局部性優(yōu)化的一種手段，成為編譯優(yōu)化領(lǐng)域的研究熱點(diǎn)。
而在Parallel Languages層面，對(duì)C&C++開(kāi)發(fā)人員，CUDA的出現(xiàn)降低了GPU的編程門檻，但GPU和CPU兩種硬件模型本質(zhì)區(qū)別，導(dǎo)致過(guò)高的開(kāi)發(fā)成本，需要學(xué)習(xí)和了解更多底層硬件細(xì)節(jié)，還更不用說(shuō)更高級(jí)語(yǔ)言的開(kāi)發(fā)語(yǔ)言像Java等所面臨的底層硬件模型與高級(jí)語(yǔ)言之間巨大的GAP。
在Java領(lǐng)域，最早在JVM技術(shù)峰會(huì)'2014，AMD曾經(jīng)分享過(guò)他們的Sumatra項(xiàng)目，嘗試實(shí)現(xiàn)JVM與Heterogeneous System Architecture目標(biāo)硬件交互。而在最近，由The University of Manchester發(fā)起的TornadoVM項(xiàng)目，實(shí)現(xiàn)包含：一個(gè)Just-in-Time編譯，支持從Java bytecode到OpenCL的映射，一個(gè)優(yōu)化的運(yùn)行時(shí)引擎，以及可以保持Java堆和異構(gòu)設(shè)備堆內(nèi)存一致性的內(nèi)存管理器。TornadoVM的目標(biāo)是開(kāi)發(fā)人員不需要了解GPU編程語(yǔ)言或者相關(guān)的GPU體系結(jié)構(gòu)知識(shí)就可以編寫面向異構(gòu)的并行程序。TornadoVM可以透明地運(yùn)行在AMD GPUs,NVIDIA GPUs,Intel integrated GPUs以及multi-core CPUs上。
在通用CPU領(lǐng)域，OpenJDK社區(qū)的Vector API項(xiàng)目(Panama的子項(xiàng)目)，依賴CPU的SIMD指令，獲得計(jì)算性能的成倍提升，Vector API在大數(shù)據(jù)，AI計(jì)算也有非常廣的應(yīng)用場(chǎng)景。阿里JVM團(tuán)隊(duì)把Vector API移植到了AJDK 11。
Polyglot Programing，鏈接多語(yǔ)言生態(tài)
Polyglot Programming并不是一個(gè)新的概念。在Managed Runtime領(lǐng)域，2017年IBM開(kāi)源Open Managed Runtime(OMR),以及2018年Oracle開(kāi)源Truffle/Graal技術(shù)。OMR和Graal技術(shù)讓開(kāi)發(fā)人員實(shí)現(xiàn)一個(gè)新的語(yǔ)言成本大幅下降。前者OMR以C、C++組件的形式提供了Garbage Collection(GC),Just-in-Time(JIT）以及Reliability,availability and serviceability(RAS，工具)等,開(kāi)發(fā)人員可以依賴這些組件，通過(guò)'glue'的方式基于這些組件實(shí)現(xiàn)自己的高性能語(yǔ)言。而后者Truffle/Graal,Truffle是一個(gè)依賴AST parser實(shí)現(xiàn)新的語(yǔ)言的Java框架，本質(zhì)上是將你的新的語(yǔ)言映射到JVM世界。不同于Scala,JRuby這些圍繞JVM生態(tài)本身構(gòu)建的語(yǔ)言，他們本質(zhì)是還是Java，無(wú)論是OMR，還是Truffle/Graal，他們都提供了生產(chǎn)級(jí)的GC，JIT，以及RAS服務(wù)支持，新開(kāi)發(fā)的語(yǔ)言完全不需要再重新實(shí)現(xiàn)這些底層技術(shù)。
從業(yè)界來(lái)看，面向特定領(lǐng)域的Domain Specific Language(DSL)語(yǔ)言已經(jīng)有向這些技術(shù)遷移的趨勢(shì)，高盛正在與Graal社區(qū)合作，把他們的DSL遷移到Graal上。另外Ruby/OMR,Python/Graal，JS/Graal，WASM/Graal等這些真正鏈接不同語(yǔ)言生態(tài)的項(xiàng)目，也正在迅速發(fā)展起來(lái)。
回到AJDK，Graal已經(jīng)在AJDK 8開(kāi)始支持，JS/Graal這樣成熟的技術(shù)，已經(jīng)在阿里內(nèi)部業(yè)務(wù)上線。
最后
Java是一項(xiàng)二十多年前被發(fā)明出來(lái)的技術(shù)，她歷經(jīng)磨難，幾易其主，但卻歷久彌新。這篇報(bào)告旨在為Java的開(kāi)發(fā)者們梳理下目前的Java技術(shù)現(xiàn)狀，以及討論在云，AI等這些重要領(lǐng)域內(nèi)Java技術(shù)的演進(jìn)趨勢(shì)。在介紹的相關(guān)部分，我們也穿插了阿里的一些工程實(shí)踐。作為世界上的Java用戶之一，我們也一直在探索把前沿的Java技術(shù)，通過(guò)在阿里豐富的業(yè)務(wù)場(chǎng)景的試驗(yàn)，真正把這些技術(shù)應(yīng)用于真實(shí)的生產(chǎn)環(huán)境。我們也非常樂(lè)于分享和貢獻(xiàn)Java領(lǐng)域的經(jīng)驗(yàn)、實(shí)踐與技術(shù)洞見(jiàn)，包括明天即將發(fā)布的《Java開(kāi)發(fā)手冊(cè)》，共同促進(jìn)Java的發(fā)展。
重慶計(jì)算機(jī)培訓(xùn)機(jī)構(gòu)哪家好
如何高效學(xué)習(xí)Java課程
Java語(yǔ)言的特點(diǎn)
Java開(kāi)發(fā)規(guī)范及其技巧分享
JAVA培訓(xùn)哪家好
Java入門學(xué)習(xí)指南