人們期待已久的Java SE 9.0將在2017年9月21日發(fā)布,,它會(huì)帶來一些重要的變化。 JDK 9的核心變化就是引入了一種新的Java編程組件,,也就是模塊,,按照Oracle的說法,它是一個(gè)可命名的,、自描述的代碼和數(shù)據(jù)集合,。 模塊技術(shù)的核心目標(biāo)是減少Java應(yīng)用和Java核心運(yùn)行時(shí)環(huán)境的大小與復(fù)雜性。為此,,JDK本身進(jìn)行了模塊化,,Oracle希望通過這種方式提升性能、安全性和可維護(hù)性,。 為了支持Java 9的模塊,,引入一種新的模塊化JAR文件形式,按照這種形式會(huì)在其根目錄中包含一個(gè)module-info.class文件,。 Oracle同時(shí)提供了工具,,允許我們組合和優(yōu)化一組模塊,,形成自定義運(yùn)行時(shí)的鏡像(image),這樣的鏡像不必將整個(gè)Java運(yùn)行時(shí)包含進(jìn)來,。 模塊化所帶來的其他變化包括從Java運(yùn)行時(shí)鏡像中移除了rt.jar和tools.jar,。 InfoQ與Ben Evans進(jìn)行了交流,以了解他對(duì)Java 9.0模塊系統(tǒng)的看法,,他是Java社區(qū)進(jìn)程(JCP)執(zhí)行委員會(huì)的成員,。 Evans:我認(rèn)為最急需重構(gòu)的應(yīng)用恰好就是最適合進(jìn)行模塊化的應(yīng)用。 如果你已經(jīng)備受Lava Flow / God Class / Stovepipe System地獄的折磨,,而且你的利益相關(guān)方明確知道這一點(diǎn),,那么你可能更容易說服他們進(jìn)行一次完整的底層重構(gòu),通過漸進(jìn)式的努力形成一個(gè)完成的模塊解決方案(而不是簡單重構(gòu)并遷移至Java 8)是值得去做的,。 Oracle宣布Java 8會(huì)是一個(gè)長期支持的發(fā)布版本,,會(huì)一直支持到2022年,因此Evans認(rèn)為很多的應(yīng)用將會(huì)停留在Java 8上,,根本不會(huì)升級(jí)到Java 9,。Evans補(bǔ)充說,,有些應(yīng)用可能會(huì)讓開發(fā)和構(gòu)建工具鏈?zhǔn)褂肑ava 8版本,,而在生產(chǎn)環(huán)境使用Java 9的運(yùn)行時(shí)。 對(duì)特定類型的應(yīng)用來說,,這是很有幫助的,。 例如,我曾經(jīng)見到有的電子商務(wù)網(wǎng)站具有非常大的堆空間,,其中包含了大約40G的字符串?dāng)?shù)據(jù),。Java 9的ompact Strings技術(shù)能夠?qū)⑦@種類型的內(nèi)存使用減半。這反過來又會(huì)對(duì)GC的性能帶來積極的影響,。 對(duì)于有些應(yīng)用來說(這可能就包括大型的Solr安裝環(huán)境及類似場景),,單單這一項(xiàng)收益就值得將運(yùn)行時(shí)升級(jí)到Java 9。 Java 9使用G1作為默認(rèn)的垃圾收集器,,替代了之前默認(rèn)使用的Parallel GC,。Evans對(duì)這項(xiàng)變化的評(píng)論: 這項(xiàng)變更是很重要的,因?yàn)橄鄬?duì)于Parallel來說,,G1會(huì)在應(yīng)用線程上做更多的事情,,而Parallel幾乎沒有在應(yīng)用線程上做任何事情,它基本上完全依賴GC線程完成所有的內(nèi)存管理,。 這意味著切換到G1將會(huì)為應(yīng)用線程帶來額外的工作,,從而直接影響到應(yīng)用的性能。 在很多(甚至可以說大多數(shù))場景中,,這種額外的性能損耗都不是什么問題,。 但是,,在這方面,我確實(shí)也曾經(jīng)見過從Parallel切換到G1時(shí),,有一定比例的工作負(fù)載會(huì)引起性能的下降,。 對(duì)于這些應(yīng)用來說,這種性能下降是無法接受的,,所以他們無法切換至G1收集器,。隨著G1成為默認(rèn)的收集器,這將會(huì)影響到升級(jí)至Java 9的每個(gè)應(yīng)用,。 對(duì)于大型的代碼庫是否需要重構(gòu)為模塊的形式,,InfoQ詢問了Martijn Verburg的意見,他是JClarity的CEO,,也是倫敦Java用戶組(Java User Group)的聯(lián)合組織者,。 Verburg:需要這樣做,另外,,我還希望你要處理的大型代碼庫已經(jīng)按照一定的模塊化結(jié)構(gòu)語義進(jìn)行了拆分,,不管你采用的是OSGi、Maven模塊,、JBoss模塊,,還是采用簡單的內(nèi)部規(guī)則,將包和接口的結(jié)構(gòu)劃分出清晰的邊界都可以,。 Verburg給出了一些通用的模塊化建議,,并且指出了開發(fā)人員在采用Java 9模塊系統(tǒng)時(shí),需要注意的一些事情:
按照Verburg的說法,核心要點(diǎn)在于處理循環(huán)依賴、拆分包的問題,,并確保針對(duì)接口進(jìn)行編碼,。在嘗試使用Jigsaw模塊化重構(gòu)之前,針對(duì)已有的代碼庫,,這些工作需要預(yù)先完成,。他還澄清了一個(gè)誤解,那就是只有模塊化的應(yīng)用才能在Java 9上運(yùn)行,。 由于誤解,,在這方面有一種FUD(恐懼、不確定和懷疑)情緒,,有人誤認(rèn)為在Java 9上運(yùn)行的必須是模塊化的應(yīng)用,。事實(shí)并非如此,我們可以將已有的基于類路徑的應(yīng)用直接在Java 9上運(yùn)行,。 這里會(huì)有一些新的安全限制,,因此我們需要設(shè)置一些特定的運(yùn)行時(shí)標(biāo)記(除非你重構(gòu)代碼,使用更安全的方式來訪問Java的內(nèi)部資源),,即便如此,,默認(rèn)的行為也只是警告,而不是完全阻止我們(Java 10的限制會(huì)更嚴(yán)格),。 Verburg認(rèn)為Jigsaw會(huì)是一個(gè)基石,,會(huì)讓Java的演進(jìn)更快,這要?dú)w功于Mark Reinhold,、Alan Bateman,、Mandy Chung以及Jigsaw團(tuán)隊(duì)的其他成員多年來不知疲倦的工作,正是他們的努力使這一切得以實(shí)現(xiàn),。 Java 9還引入了jshell工具。這個(gè)命令行環(huán)境為Java平臺(tái)帶來了讀入-求值-打印-循環(huán)(Read-Eval-Print-Loop,,REPL)功能,。它的目的在于以即時(shí)結(jié)果和反饋的形式,簡化原型的實(shí)現(xiàn)并幫助我們探索語言在編碼時(shí)的可選項(xiàng),。 Verburg和Evans看到Java 9中包含了jShell都非常興奮,,但令他們失望的是,HTTP/2只是作為Java 9的一個(gè)孵化模塊(incubator module)提供的,。鑒于社區(qū)對(duì)這項(xiàng)特性的興趣和提供的幫助,,Evans認(rèn)為Oracle應(yīng)該投入足夠的工程資源,將HTTP/2交付為GA版本,。 JDK 9完整的變更列表可以在Oracle的站點(diǎn)上查閱,。Oracle宣布會(huì)按照每六個(gè)月一次的節(jié)奏進(jìn)行發(fā)布,意味著Java 9是最后一次“keystone”特性驅(qū)動(dòng)的版本發(fā)布,,這反映出了Oracle目前管理Java的特點(diǎn),。 Java下一階段的演化將會(huì)按照更短的發(fā)布周期并且會(huì)按照更加面向特性的方式來發(fā)布,。Java是否依然能夠在服務(wù)端技術(shù)中占據(jù)領(lǐng)導(dǎo)者地位尚有待觀察。 附相關(guān)解讀:
首先,,談到 Java 9 大家往往第一個(gè)想到的就是 Jigsaw 項(xiàng)目,這是一個(gè)雄心勃勃的項(xiàng)目,。 大家知道,,Java 已經(jīng)發(fā)展超過 20 年(95 年最初發(fā)布),Java 和相關(guān)生態(tài)在不斷豐富的同時(shí)也越來越暴露出一些問題,,比如 Java 運(yùn)行環(huán)境的膨脹和臃腫,,各種類庫和工具在提供強(qiáng)大功能的同時(shí),也越來越復(fù)雜,,不同版本的類庫交叉依賴導(dǎo)致 Jar Hell 等讓人頭疼的問題,,這些都阻礙了 Java 開發(fā)和運(yùn)行效率的提升。 但是由于兼容性等各方面的掣肘,,對(duì) Java 進(jìn)行大刀闊斧的革新越來越困難,,Jigsaw 從 Java 7 階段就開始籌備,Java 8 階段進(jìn)行了大量工作,,終于在 Java 9 里落地,,有種千呼萬喚始出來的意味。 Jigsaw 項(xiàng)目的目標(biāo)是改進(jìn) Java SE 平臺(tái),,使其可以適應(yīng)不同大小的計(jì)算設(shè)備,;改進(jìn)其安全性,可維護(hù)性,,提高性能,;簡化各種類庫和大型應(yīng)用的開發(fā)和維護(hù)。 這個(gè)項(xiàng)目的工作量和難度大大超出了初始規(guī)劃,。JSR 376 Java 平臺(tái)模塊化系統(tǒng)(JPMS, Java Platform Module System)作為 Jigsaw 項(xiàng)目的核心, 其主體部分被分解成 6 個(gè) JEP(JDK Enhancement Proposals)
可以看到這是一個(gè)龐大的系統(tǒng)工程,,Java 的方方面面,包括 JDK 編譯工具,運(yùn)行時(shí),,Java 公共 API 和私有代碼等等,,完全是一個(gè)整體性的改變。 隨著 Java 平臺(tái)模塊化系統(tǒng)的落地,,開發(fā)人員無需再為不斷膨脹的 Java 平臺(tái)苦惱,,例如,您可以使用 jlink 工具,,根據(jù)需要定制運(yùn)行時(shí)環(huán)境,。這對(duì)于擁有大量鏡像的容器應(yīng)用場景或復(fù)雜依賴關(guān)系的大型應(yīng)用等,都具有非常重要的意義,。 從軟件開發(fā)實(shí)踐的角度,,Java 語言層面提供對(duì)模塊的支持,可以鼓勵(lì)(當(dāng)然在某種程度上也可以看作強(qiáng)制)更加規(guī)范的開發(fā)實(shí)踐,,利用業(yè)界在開發(fā)領(lǐng)域幾十年的經(jīng)驗(yàn),、教訓(xùn)總結(jié)出的最佳實(shí)踐,促進(jìn) Java 生態(tài)的健康發(fā)展,。比如,,更加完善的隱藏實(shí)現(xiàn)細(xì)節(jié),這不僅可以促進(jìn)面向接口,、約定的編程,,也可以避免可能的安全風(fēng)險(xiǎn)等。 不過,,換個(gè)角度來說,,天下沒有免費(fèi)的午餐,由于 JPMS 是語言平臺(tái)層面的支持,,它并不是完全透明的,,也就是說不管用戶是否真的需要或從中收益,都會(huì)或多或少的受其影響,。 對(duì)此,,我們可以從 JPMS 評(píng)審中針對(duì)類似深度反射限制之類的激烈爭吵中,深刻體會(huì)到,。比如,針對(duì)反射訪問控制,,最終 Java 9 開發(fā)團(tuán)隊(duì),,采取了相對(duì)折中的辦法,在反射領(lǐng)域默認(rèn)保持 Java 8 的默認(rèn)行為,。Java 9 在兼容性方面,,相比于過往的版本,采取了更大的容忍度。 不過,,Java 9 的相當(dāng)一部分特性仍然是對(duì)用戶透明的,。只要升級(jí)到 Java 9,不需要或者很少需要用戶參與動(dòng)作就能獲益,。比如,,更加緊湊的字符串實(shí)現(xiàn);改進(jìn)的競爭鎖機(jī)制,;改進(jìn)安全應(yīng)用性能 ,;利用特定 CPU 指令優(yōu)化 GHASH 和 RSA 等等,這些都是開箱即用,、觸手可得的改進(jìn),。 對(duì)于部分開發(fā)者來說,探究 Java 內(nèi)部 API 或者平臺(tái)底層能力是一件非??岬氖虑?,但這往往并不是非常容易,比如部分能力可能并沒有在歷史版本的公共 API 中暴露出來(比如 Unsafe 相關(guān)),,或者需要特定領(lǐng)域的知識(shí),。在 Java 9 中,不要錯(cuò)過 JEP 193: Variable Handles 和 JEP 274: Enhanced Method Handles,,JEP 259: Stack-Walking API,,JEP 285: Spin-Wait Hints 等特性。 另外,,Java 9 中還有很多承上啟下的特性,,為未來創(chuàng)新打下基礎(chǔ)或者整合、規(guī)范現(xiàn)有碎片化的功能,,我會(huì)介紹一些有代表性的新特性,。 在 Java 虛擬機(jī)領(lǐng)域,JEP 271: Unified GC Logging 和 JEP 158:Unified JVM Logging,,對(duì)各種 JVM 日志進(jìn)行了統(tǒng)一,,大家終于不用為各種碎片化的日志選項(xiàng)苦惱了。 Oracle 一直在努力提高 Java 啟動(dòng)和運(yùn)行時(shí)性能,,希望其能夠在更廣泛的場景達(dá)到或接近本地語言的性能,。但是,直到今天,,談到 Java,,很多 C/C 開發(fā)者還是會(huì)不屑地評(píng)價(jià)為啟動(dòng)慢,吃內(nèi)存,。 簡單說,,這主要是因?yàn)?Java 編譯產(chǎn)生的類文件是 Java 虛擬機(jī)可以理解的二進(jìn)制代碼,,而不是真正的可執(zhí)行的本地代碼,需要 Java 虛擬機(jī)進(jìn)行解釋和編譯,,這帶來了額外的開銷,。 JIT(Just-in-time)編譯器可以在運(yùn)行時(shí)將熱點(diǎn)編譯成本地代碼,但是實(shí)際應(yīng)用可能非常龐大,,大型 Java 應(yīng)用的預(yù)熱往往非常耗時(shí),,而且非熱點(diǎn)代碼可能根本沒有機(jī)會(huì)被 JIT 編譯。 在 JDK 9 中,, AOT(JEP 295: Ahead-of-Time Compilation)作為實(shí)驗(yàn)特性被引入進(jìn)來,,開發(fā)者可以利用新的 jaotc 工具將重點(diǎn)代碼轉(zhuǎn)換成類似類庫一樣的文件,這樣會(huì)大大降低啟動(dòng)開銷,。 另外 JVMCI (JEP 243: Java-Level JVM Compiler Interface)等特性,,對(duì)于整個(gè)編程語言的發(fā)展,可能都具有非常重要的意義,,雖然未必引起了廣泛關(guān)注,。目前 Graal Core API 已經(jīng)被集成進(jìn)入 Java 9,雖然還只是初始一小步,,但是完全用 Java 語言來實(shí)現(xiàn)的可靠的,、高性能的動(dòng)態(tài)編譯器,似乎不再是遙不可及,,這是 Java 虛擬機(jī)開發(fā)工程師的福音,。 與此同時(shí),隨著 Truffle 框架和 Substrate VM 的發(fā)展,,已經(jīng)讓個(gè)別信心滿滿的工程師高呼“One VM to Rule Them All!”,, 也許就在不遠(yuǎn)的將來 Ploygot 以一種另類的方式成為現(xiàn)實(shí)。 前面簡短地談了談 Java 9 中的一些令人激動(dòng)的特性,,Java 9 在取得這些進(jìn)步的同時(shí),,那么在其的研發(fā)過程中有哪些教訓(xùn),當(dāng)前和未來遇到了那些挑戰(zhàn)呢,? 首先,,就是如何更加快速、敏捷地進(jìn)行創(chuàng)新,。在 Java 9 的開發(fā)過程中, 非常突出的一點(diǎn)就是,,由于 Jigsaw 項(xiàng)目的延期,導(dǎo)致 Java 9 的發(fā)布一再推遲,,這帶來了很多負(fù)面影響,。大批特性已經(jīng)完成多時(shí),卻無法及時(shí)被實(shí)際應(yīng)用采納,,開發(fā)者無法及時(shí)地從中獲益,,也很難盡早發(fā)現(xiàn)和反饋可能存在的問題或改進(jìn)。這不禁讓人反思 Java 傳統(tǒng)的研發(fā)模式的局限性,。 針對(duì)這些情況,,Java 首席架構(gòu)師 Mark Reinhold 已經(jīng)發(fā)出倡議,建議從傳統(tǒng)的以特性驅(qū)動(dòng)的發(fā)布周期,,轉(zhuǎn)變?yōu)橐詴r(shí)間驅(qū)動(dòng)的(6 個(gè)月為周期)發(fā)布模式,,并逐步的將 Oracle JDK 原有商業(yè)特性進(jìn)行開源,Java Flight Recorder 等殺手級(jí)工具和特性,,一定會(huì)大受開發(fā)者的歡迎,。針對(duì)企業(yè)客戶的需求,Oracle 將以三年為周期發(fā)布長期支持版本(long term support),。 第二,,隨著云計(jì)算和 AI 等技術(shù)浪潮,當(dāng)前的計(jì)算模式和場景正在發(fā)生翻天覆地的變化,,不僅對(duì) Java 的發(fā)展速度提出了更高要求,,也深刻影響著 Java 技術(shù)的發(fā)展方向。傳統(tǒng)的大型企業(yè)或互聯(lián)網(wǎng)應(yīng)用,,正在被云端,,容器化應(yīng)用、模塊化的微服務(wù)甚至是函數(shù)(FaaS,, Function-as-a-Service)所替代,。 Java 需要在新的計(jì)算場景下,改進(jìn)開發(fā)效率,。這話說的有點(diǎn)籠統(tǒng),,我談一些自己的體會(huì),Java 代碼雖然進(jìn)行了一些類型推斷等改進(jìn),,更易用的集合 API 等,,但仍然給開發(fā)者留下了過于刻板、形式主義的印象,,這是一個(gè)長期的改進(jìn)方向,,例如,JEP 286: Local-Variable Type Inference,;持續(xù)改進(jìn)并發(fā)計(jì)算框架,,Java 的并發(fā)特性非常強(qiáng)大和系統(tǒng),但某種程度上過于復(fù)雜,,在今年的 JVMLS 上,,阿里巴巴 AJDK 組介紹了利用協(xié)程改進(jìn)并發(fā)的實(shí)踐,這是一個(gè)令人眼前一亮的創(chuàng)新,;Java 非常需要更加友好的本地代碼支持,,相關(guān)的特性有很多好的想法和嘗試,,比如 Panama 項(xiàng)目;Value Types 和改進(jìn)的泛型,,有興趣可以參考 Valhalla 項(xiàng)目,。 最后,進(jìn)一步改進(jìn)啟動(dòng)和運(yùn)行性能,、優(yōu)化計(jì)算資源使用,。目前,相當(dāng)一部分的 Java 類庫和虛擬機(jī)特性都是針對(duì)長時(shí)間,、大數(shù)據(jù)量,、高并發(fā)等復(fù)雜任務(wù)進(jìn)行的優(yōu)化,但是在部分云計(jì)算場景中,,比如越來越引起大家關(guān)注的 FaaS 應(yīng)用,,短時(shí)間、無狀態(tài)的函數(shù)正在成為常見的計(jì)算單元,。那么在這種場景下,,Java 必須進(jìn)行相應(yīng)的改進(jìn)和創(chuàng)新,才能保持和強(qiáng)化目前在軟件開發(fā)領(lǐng)域的競爭力,。比如,,提高 Java 運(yùn)行時(shí)啟動(dòng)速度,尤其是在容器環(huán)境的初始化表現(xiàn),;保證 CPU 等計(jì)算資源調(diào)度能力能夠適應(yīng)容器環(huán)境的新情況,,最直接的就是 Java 平臺(tái)需要支持基于 cgroup 等技術(shù)的資源管理;針對(duì)新場景下的 GC 優(yōu)化,;如何提高數(shù)據(jù)密度和計(jì)算效率等等,。 以上很多方面往往不是孤立的,也不是非常簡單就可以完成的,,很多改進(jìn)都是依賴于相關(guān)語言基礎(chǔ)技術(shù)的進(jìn)步和突破,,Java 的進(jìn)步需要持之以恒的耐心和持續(xù)的努力與投入。 最后,,歡迎大家能夠參與到 OpenJDK 社區(qū),,Java 是大家的,歡迎您向 OpenJDK 提供建議,、意見或者直接提交自己的改進(jìn),,在社區(qū)中聽見越來越多的來自中國的聲音是非常令人高興的事情,讓我們攜手促進(jìn) Java 的創(chuàng)新和發(fā)展,。 |
|