不需要jre運(yùn)行Java？你沒(méi)看錯(cuò)！
今天我們要介紹的是spring-native，它可以讓你的spring boot程序，體驗(yàn)graalvm編譯器的特性，把你的應(yīng)用直接編譯成native的!
不需要再安裝jre，你的應(yīng)用程序?qū)⒑蚭xe一樣，直接在目標(biāo)機(jī)器上運(yùn)行!而且啟動(dòng)時(shí)間不到1秒鐘。
要體驗(yàn)這個(gè)功能，我們從spring boot拿一個(gè)demo。
https://start.spring.io/
在這里選擇這個(gè)實(shí)驗(yàn)性的功能SpringNative。下載下來(lái)之后，就可以使用maven進(jìn)行打包測(cè)試。
- mvn spring-boot:build-image
- gradle bootBuildImage
看一下這無(wú)敵的啟動(dòng)速度.... 0.038秒... 幾乎是瞬時(shí)的!
神奇!
這一切，都得益于graalvm編譯器。不過(guò)，你至少要把JDK升級(jí)到11才能用，也算是堆Java8用戶的一種別樣的驅(qū)動(dòng)吧。
當(dāng)然，只有在2.4.5以后的SpringBoot版本中，才支持Spring Native。
GraalVM是什么?
graalvm也是oracle的項(xiàng)目，它的代碼地址是：https://github.com/oracle/graal
項(xiàng)目地址是：www.graalvm.org/docs/
graalvm是一個(gè)想要統(tǒng)一天下的虛擬機(jī)。因?yàn)樗啾容^與HotSpotVM，還能夠運(yùn)行其他語(yǔ)言比如ruby，python，php等。
它是一個(gè)新的JVM，不同的是由于做了適配，它能夠讓不同的語(yǔ)言跑在同一個(gè)vm下面。
看看下面這張圖，就知道graalvm的野心有多大。
這還沒(méi)完，它最吸引人的地方就在于，它能夠?qū)?yīng)用代碼，直接打包成native的二進(jìn)制可執(zhí)行代碼，運(yùn)行時(shí)連JVM都不需要了!
大家都知道，native和跑在vm里完全是兩個(gè)檔次，否則也不會(huì)有jit這么牛x的技術(shù)存在了。連android和ios都知道，native的應(yīng)用流暢性比跑在monotouch上或者h(yuǎn)ybrid上高很多很多，對(duì)于追求性能的企業(yè)級(jí)應(yīng)用來(lái)說(shuō)，這個(gè)功能就更加實(shí)用一些。
讓人驚訝的是，它為各個(gè)語(yǔ)言實(shí)現(xiàn)了一個(gè)可以溝通的橋梁。比如我看好js中的某個(gè)庫(kù)，不需要重新開(kāi)發(fā)一個(gè)了，在Java中直接就可以用。這是因?yàn)?，graalVM開(kāi)發(fā)了跨語(yǔ)言互操作協(xié)議，能保證跨語(yǔ)言的互操作性。
現(xiàn)在這個(gè)功能，大多數(shù)平臺(tái)已經(jīng)支持了。
什么叫做native呢?考慮下面這份代碼。
- public class Example {
- public static void main(String[] args) {
- String str = "Native Image is awesome";
- String reversed = reverseString(str);
- System.out.println("The reversed string is: " + reversed);
- }
- public static String reverseString(String str) {
- if (str.isEmpty())
- return str;
- return reverseString(str.substring(1)) + str.charAt(0);
- }
- }
通常情況下，我們直接這樣運(yùn)行，或者打包成jar包。
- javac Example.java
- java Example
但我們還可以多一步，就是把class文件native化。
- native-image Example
執(zhí)行的時(shí)候，只需要輸入 ./Example 就可以了。
有什么好處?
使用native編譯的應(yīng)用，可以實(shí)現(xiàn)秒級(jí)別的啟動(dòng)，運(yùn)行更快，占用內(nèi)存更小。它與主流的部署方式如微服務(wù)、k8s等，更加的切合。
但它與傳統(tǒng)的JVM也有很多不同，主要體現(xiàn)在：
- 系統(tǒng)的性能分析會(huì)在編譯階段就給出
- 沒(méi)用的部分和代碼將不會(huì)編譯，直接會(huì)被移除，這得益于前些java版本的模塊化
- 需要提前對(duì)反射、資源和動(dòng)態(tài)代理進(jìn)行轉(zhuǎn)換，沒(méi)有類加載的延遲
- classpath在編譯階段固定
- class將不會(huì)被懶加載，回在啟動(dòng)的時(shí)候一股腦放到內(nèi)存
雖然native有很多好處，但它的編譯時(shí)間卻很長(zhǎng)，因?yàn)橐龃罅康拇a靜態(tài)分析，這也是所有native程序的通病吧。
End
這種thin jar的思路，是不是感覺(jué)Java的發(fā)展越來(lái)越像golang了呢?docker鏡像也會(huì)因?yàn)檫@種改變便得更小更純粹，而脫離jre的Java應(yīng)用也越來(lái)越像一個(gè)真正的程序了。
但可惜的是，這種編譯成native的思路雖然好，現(xiàn)階段還是無(wú)法和golang相抗衡，主要還是在于編譯器的差異上。
但愿graalvm能夠繼續(xù)發(fā)力，帶java繼續(xù)飛上幾十年，養(yǎng)我三代子孫!
