java的危机？

来源：珠海达内IT教育培训学校时间：2020/12/8 15:12:59

Java与云原生的矛盾，来源于Java诞生之初，植入到它基因之中的一些基本的前提假设已经逐渐开始被动摇，甚至已经不再成立。
我举个例子，每一位Java的使用者都听说过“一次编写，到处运行”（WriteOnce,RunAnywhere）这句口号。20多年前，Java成熟之前，开发者如果希望程序在Linux、Solaris、Windows等不同平台，在x86、AMD64、SPARC、MIPS、ARM等不同指令集架构上都能正常运行，就必须针对每种组合，编译出对应的二进制发行包，或者索性直接分发源代码，由使用者在自己的平台上编译。

面对这个问题，Java通过语言层虚拟化的方式，令每一个Java应用都自动取得平台无关（PlatformIndependent）、架构中立（ArchitectureNeutral）的先天优势，让同一套程序格式得以在不同指令集架构、不同操作系统环境下都能运行且得到一致的结果，不仅方便了程序的分发，还避免了各种平台下内存模型、线程模型、字节序等底层细节差异对程序编写的干扰。在当年，Java的这种设计带有令人趋之若鹜的强大吸引力，直接开启了托管语言（ManagedLanguage，如Java、.NET）的一段兴盛期。

如果仅仅是优势的削弱，并不足以成为Java的直接威胁，充其量只是一个潜在的不利因素，但更加迫在眉睫的风险来自于那些与技术潮流直接冲突的假设。譬如，Java总体上是面向大规模、长时间的服务端应用而设计的，严(luō)谨(suō)的语法利于约束所有人写出较一致的代码；静态类型动态链接的语言结构，利于多人协作开发，让软件触及更大规模；即时编译器、性能制导优化、垃圾收集子系统等Java具代表性的技术特征，都是为了便于长时间运行的程序能享受到硬件规模发展的红利。
软件工业中已经出现过不止一起因Java这些弱点而导致失败的案例，如JRuby编写的Logstash，原本是同时承担部署在节点上的收集端（Shipper）和专门转换处理的服务端（Master）的职责，后来因为资源占用的原因，被Elstaic.co用Golang的Filebeat代替了Shipper部分的职能；又如Scala语言编写的边车代理Linkerd，作为服务网格概念的提出者，却终被Envoy所取代，其主要弱点之一也是由于Java虚拟机的资源消耗所带来的劣势。
虽然在云原生时代依然有很多适合Java发挥的领域，但是具备弹性与韧性、随时可以中断重启的微型服务的确已经形成了一股潮流，在逐步蚕食大型系统的领地。正是由于潮流趋势的改变，新一代的语言与技术尤其重视轻量化和响应能力，大多又重新回归到了原生语言（NativeLanguage，如Golang、Rust）之上。

领取试听课

每天限量名额，先到先得

尊重原创文章，转载请注明出处与链接：http://www.peixun360.com/1780/news/292493/违者必究！以上就是珠海达内IT教育培训学校小编为您整理 java的危机？的全部内容。