Spring Native是未来吗?
Posted 境悟初
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了Spring Native是未来吗?相关的知识,希望对你有一定的参考价值。
当出现一个新技术时,我们不是无脑的学习,而需要思考这门技术为什么出现?为什么是这个时候出现?以及它的未来在哪里?想清楚了之后,再考虑是否学习和使用。经过社会的毒打之后,只剩下这点不多的灵魂,慰藉青春的在天之灵。
所以,spring native支持将项目打包成可执行文件,这意味着什么?
这个问题等价于:可执行文件的优缺点在哪里?我们为什么要使用?
可执行文件的优缺点
优点
在我看来有以下几个好处:
- 包更小:都是二进制,而不是还需要二次解析的class文件;
- 启动速度快:不像JVM启动会有个预热过程;
- 消耗资源更少:这里主要是指内存,因为没有JVM的开销了。
当然,可执行文件对应的缺点也是存在的。
缺点
目前将Java编译成静态文件的东西也是个VM,这就是 GraalVM,已经有国人写了相关书籍,大家可以看看。
在 GraalVM的官方里,也列举了一些限制。不过,在我看来,这些问题是可以解决的。
而比较大的问题有2个。
跨平台
这其实和Java最初宣传的口号(一次编译,到处运行)相违背。
Java应用最大的特点就是跨平台,能在易用性和性能之间取得良好的平衡,这是Java能够这么流行的关键原因。然而,编译成二进制就需要看平台了。
动态代码生成
动态代码生成技术在Java里用的很常见,很多框架都使用了,最常见的是SQL执行框架,比如 Apache Calcite,Spark SQL, 每个SQL是不确定的,SQL的执行计划也不确定,就需要使用代码生成物理执行计划。
我们知道,代码需要经过 预处理、编译、优化、汇编、链接等步骤才能变成可执行文件,在JVM里的class文件很容易实现这个功能。但是只有一个可执行文件时遇到代码生成怎么办?
我们以Go语言为例,Go语言到目前为止是做不到的。仔细想想可知,编译Go能够那么快,因为有Go的编译环境,在每台运行的机器上都装上Go的编译环境也是可以实现的,不过真有人这样做吗?这不就和每台机器都安装JDK一样的道理嘛。
所以,我觉得这个功能不会是这样实现的,这等价于一个可执行文件需要自带编译器,这包的大小也不会小吧。
为什么需要spring native?
经过上面的缺点分析,我们可以知道:Spring native是绝不可能用在所有场景的。至少Spring的定位是做业务系统,而不是中间件,所以那些底层的代理、反射技术,业务系统一般不会用。所以,写底层中间件的同志们可能要失望了,这个native不是那么好用的。
而关于它的优点才是我们要关注的,这几个小、快、少的特点在哪些场景亟需?------ 容器化、微服务。
相信使用Spring Cloud做微服务的同志深有体会,微服务的理念是什么?“微”,我就一个简单的接口,20MB的jar包就来了,对于开发者和部署来说实在不友好。
现在是云时代,设计应用的时候考虑什么?能在云上运行,这就是云原生的概念。而k8s
和docker
是云时代事实上的王者。
Java这个老年人要适应新时代,势必要做出一些改变。
可能Java也早就感觉到其下降的市场份额&强大的竞争者,比如Python和Go,特别是Go。这一举措显然是在和Go竞争,也是未来的一个趋势吧。
听起来不错,用起来就不爽了
想要跃跃欲试的同学已经按捺不住了,不过,事实很骨感,先不说Spring Native才刚发出 Beta版不久。就算稳定了,也不会倒退支持JDK8,因为下面是其支持的环境:
- Java 11, Java 17 and Kotlin 1.5+
- docker 或者 GraalVM
- springboot版本目前只支持
2.6.2
一个是JDK至少要11,Spingboot版本也非常高。对于咱们大多数还在使用JDK8的公司来说,这个升级代价有点大。不过至少又多了一丝希望和助力。
所以,Spring Native是未来吗?
当然是呀,因为未来还很遥远,我们走着瞧!
以上是关于Spring Native是未来吗?的主要内容,如果未能解决你的问题,请参考以下文章