java(java培训机构哪些好)

及時行樂 2023-11-17 21:10:36 网友分享

一些杂想:Java老矣,尚能饭否?

1000万云上开发者,全栈云产品0元试用:点击「链接」免费试用,即刻开启云上实践之旅!

本文就Java真的老了吗展开讲述,诠释了作者作为一名Java开发者的所思所感。

作者 | 傅健丰(健风)

来源 | 阿里开发者公众号

最近抽空看了Go、Rust等一些语言的新版本特性,还有云原生的一些基础设施(Docker,Kubernetes,ServiceMesh,Dapr,Serverless),有点感慨Go真的是云原生的“一等公民”,像是启动速度快、依赖少、内存占用少、Goroutine 并发等无一不是击中Java的软肋。然后突发奇想在Google上搜了下“Java老矣”,能搜出520,000条结果。不禁想问:Java真的老了吗?

“落寞”的Java

自1995年出生以来,Java已经有27年历史了,曾经的风吹雨打风吹去,一些优秀的设计在今天看来似乎并不那么重要甚至过时了。比方说:

"Write Once, Run Everywhere"的平台无关特性在当年确实是真香,但现在这种部署的便利性已经完全可以交由Docker为代表的的容器提供了(从某种意义上说,JVM也是字节码的容器),而且做得更好,可以将整个运行环境进行打包。想想Docker的口号也是:"Build Once, Run Anywhere"。Java 总体上是面向大规模、长时间运行的服务端应用而设计的。在语法层面,Java+Spring框架写出的代码一致性很高;在运行期,有JIT编译、GC等组件保障应用稳定可靠。这些特性对于企业级应用十分关键,曾经是Java最大的优势之一。但在微服务化甚至Serverless化的部署形态下,有了高可用的服务集群,也无须追求单个服务要 7×24 小时不可间断地运行,它们随时可以中断和更新,Java的这一优势无形中被削弱了。

另一个广为诟病的是Java的资源占用问题,这主要包含两方面:静态的程序大小和动态的内存占用。

不管多大的应用,都要随身带一个臃肿的JRE环境(这里先不讨论模块化改造),加上各种复杂的Jar包依赖,看了下我们团队的每个Java应用的容器镜像大小都轻松上G。应用的运行期内存占用居高不下,这个是Java天生的缺陷,很难克服。

Java的启动时间也是一大心病,主要原因在于启动时虚拟机初始化和大量类加载的时间开销(当然还有一个罪魁祸首是Spring的bean初始化,我之前写了个异步初始化Spring Bean的starter rhino-boot-turbo,把串行改并行启动速度会快很多)。本身镜像体积大,拉取时间就长,再加上分钟级的启动时间,部署应用就更显得慢了。传统的企业应用更看重长时间运行的稳定性,重启和发布频率相对较低,对启动时间相对没那么敏感,然而对于需要快速迭代、水平扩展的微服务应用而言,更快的的启动速度就意味着更高的交付效率和更加快速的回滚。尤其是对于Serverless应用或函数,冷启动速度至关重要,之前看AWS Lambda函数允许最多运行5分钟,很难想象还要花一分钟时间先启动。

云原生的潮流滚滚而来,Java的这些缺陷在要求快速交付的大环境下显得格格不入,难怪Java与Go、Rust等原生语言相比,会显得“落寞”了。

作为一个Java程序员,肯定想问,Java还有机会吗?想起有位长者说过:一个人的命运啊,当然要靠自我的奋斗,另一方面,也要考虑历史的进程。我想把它改成:Java的命运啊,当然要靠自身的努力,另一方面,也要考虑队友们给不给力。

JDK的演进

我们的大部分系统都还跑在Java 8之上,因此作为开发同学对Java 8也是最熟悉的。从Java 9开始,JDK的版本号堪比版本狂魔Chrome涨得飞快,除去开发者能够肉眼感知的语法和API的变动(Productivity)之外,Java也在性能(Performance)上一直努力。

我捋了一下OpenJDK官网[1]从Java 9开始的JEP列表,按照个人理解列出了关键的一些特性。

Java 9:难产的模块化

在数次delay之后,Java 9终于正式引入了Java平台模块系统(JPMS),项目代号Jigsaw。在这之前,Java以package对代码进行组织,再将package和资源打成Jar包,模块则在package的概念上将多个逻辑上、功能上相关的包以及相关的资源文件封装成模块。关于模块的详细介绍,可以参考下官方的介绍文档:Understanding Java 9 Modules[2]。

此前,Java Runtime的庞大臃肿一直为人诟病(一个rt.jar就有60多M,整个JRE环境可以达到上百M),瘦身正是Project Jigsaw的目标[3]之一。此外,还有Jar Hell、安全性等等问题。

不过模块化看着很好,也隐藏着陷阱:

不可忽视的改造成本虽然提供了未命名模块和自动模块,Oracle也提供了迁移指南和工具[4]供参考,但改造的成本依旧很大,特别是梳理模块之间的依赖关系,较为繁琐。小心使用内部API模块化的最大卖点之一是强大的封装性,它确保非public类以及非导出包中的类无法从模块外部访问。但在这之前,jar包中类的访问是没有限制的(即使是private也可以通过反射访问)。比如JDK中的大部分com.sun.* 和 sun.*包是内部无法访问的,但这之前被用得很多(出于性能/向前兼容等等原因),虽然Oracle的建议是不要使用这些类:Why Developers Should Not Write Programs That Call 'sun' Packages[5]。小心使用内部JAR像lib/rt.jar和lib/tools.jar等内部 JAR不能再访问了。不过正常来说,应该只有IDE或类似工具会直接依赖?小心使用JAR中的资源一些API会在运行期获取JAR中的资源文件(例如通过ClassLoader.getSystemResource),在Java9之前会拿到 jar:file:<path-to-jar>!<path-to-file-in-jar>这类格式的URL Schema,而Java9之后则变成了 jrt:/<module-name>/<path-to-file-in-module>其他一些问题[6]

对于新的项目,使用模块构建似乎是值得的,但现状是,大多数开发者会忽略模块系统,尤其是对于已经运行了多年的大型项目,改造的成本令人望而却步。我猜测肯定会有人吐槽类似的问题:

我已经分成不同jar包了,我感觉这样就可以了,有必要更进一步吗?我又不是开发中间件和框架的,我开发业务应用,为什么要关心这些?就算我有二方包要开放出去,为二方包维护模块定义似乎也带不来多少收益?该如何分离每个模块,基于什么原则?就跟DDD一样,我知道这东西很美好,有最佳实践可以参考吗?

搜了一下,似乎国外网友也有一样的疑惑[7]。不过,我认为让程序员可以定义应用程序的模块是什么,它们将如何被其他模块使用,以及它们依赖于哪些其他模块,这些事情还是有必要做的。

当然Java9除了模块化之外,还有一些其他特性也值得关注:

compact strings[8],通过对底层存储的优化来减少String的内存占用。String对象往往是堆内存的大头(通常来说可以达到25%),compact string可以减少最多一倍的内存占用;AOT编译[9],一个实验性的AOT编译工具jaotc[10]。它借助了Graal编译器,将所输入的Java类文件转换为机器码,并存放至生成的动态共享库之中。jaotc的一大应用便是编译java.base module(也就是模块化后Java核心类库中最为基础的类)。这些类很有可能会被应用程序所调用,但调用频率未必高到能够触发即时编译。JVMCI[11]( JVM 编译器接口),另一个experimental的编译特性。用Java写Java编译器,Java也可以说我能自举了!

关于 JVMCI 多介绍一些。相比用 C 或 C++ 编写的现有编译器(说的就是你,C2),用Java写编译器更容易维护和改进。JVMCI的API 提供了访问 JVM 结构、安装编译代码和插入 JVM 编译系统的机制,后面讲到的Graal正是基于JVMCI。

JVMCIJIT编译器与JVM的交互可以分为如下三个方面。

响应编译请求;

获取编译所需的元数据(如类、方法、字段)和反映程序执行状态的profile;

将生成的二进制码部署至代码缓存(code cache)里。

即时编译器通过这三个功能组成了一个响应编译请求、获取编译所需的数据,完成编译并部署的完整编译周期。

传统情况下,即时编译器是与Java虚拟机紧耦合的。也就是说,对即时编译器的更改需要重新编译整个Java虚拟机。这对于开发相对活跃的Graal来说显然是不可接受的。

为了让Java虚拟机与Graal解耦合,引入 JVMCI 将上述三个功能抽象成一个Java层面的接口。这样一来,在Graal所依赖的JVMCI版本不变的情况下,我们仅需要替换Graal编译器相关的jar包(Java 9以后的jmod文件),便可完成对Graal的升级。

其实JVMCI接口就长这样:

public interface JVMCICompiler {/*** Services a compilation request. This object should compile the method to machine code and* install it in the code cache if the compilation is successful.*/CompilationRequestResult compileMethod(CompilationRequest request);}

剩余60%,完整内容请点击下方链接查看:

一些杂想:Java老矣,尚能饭否?

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

Java线下培训和线上的区别?记下这些!

Java学习有很多方式,培训还是自学?线上还是线下?录播课还是直播课,一直都是大家关注的问题。对于学习Java的人来说,他们可以选择参加线下培训或线上培训。那么,这两种学习方式之间有什么区别呢?从学习方式不同对学习效果产生的影响的角度来看,我们可以分析这个问题。

首先,从线下培训的角度来看,它具有互动性强、实践性强等优点。在线下培训中,学员可以和老师面对面交流,老师可以及时解答学员的问题,学员也可以通过课堂上的练习来巩固所学知识。此外,线下培训还可以提供一些实践机会,让学员在实际项目中应用所学知识,从而更好地掌握Java编程技能。

相比之下,线上培训的优点在于灵活性、便捷性等方面。线上培训可以随时随地进行,学员可以根据自己的时间安排进行学习,不必受到时间和地点的限制。此外,线上培训费用通常比较低,对于一些经济条件不太好的学员来说,是一种不错的选择。

综上所述,无论是线下培训还是线上培训,都有其优点和缺点。对于学习Java的人来说,应该根据自己的实际情况选择适合自己的学习方式。如果时间和经济条件允许,可以选择参加线下培训,从而获得更好的互动性和实践机会。如果时间和经济条件比较紧张,可以选择线上培训,但要注意选择正规的培训机构,避免浪费时间和金钱。

免责声明:本文内容由互联网用户自发贡献,该文观点仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容,请发送邮件举报,一经查实,本站将立刻删除。

扫一扫在手机阅读、分享本文