Java 很强,但是 Java 的路还很长

2023-06-20 22:24:04 +08:00
 karottc

看了隔壁吹爆 java21 的帖子之后,我去详细研读了下 Java21 的新特性。

首先承认,这么多年了,Java 的强已经被证明了,毋庸质疑,但是 Java 也有各种弱点(这里就不说了)。

其次,Java21 两大更新:虚拟线程正式版,分代 ZGC 。确实也非常的好,但是远没到吹爆的程度。

尤其是虚拟线程,这个光秃秃的虚拟线程,如果没有配套的话,完全不足以促使现有框架大规模适配,这是我仔细阅读 Java21 相关 JEP 之后的感觉。

因为和虚拟线程配套的两个重要特性在 Java21 上还是预览版,还不是正式版,所以目前虚拟线程场景虽然正式版了,但是场景还很受限。

和虚拟线程配套的两个重要特性是:

  1. 结构性并发: https://openjdk.org/jeps/453
  2. 范围值: https://openjdk.org/jeps/446

有兴趣的朋友,我也强烈建议大家仔细阅读下,读完了,一定回过头来同意我上面的观点——虚拟线程虽好,但还需要完善配套。

只有一个虚拟线程,现有框架就不会大量跟进,那么生态就不会有大变化,基本还是还目前一样。

然而等这两个配套上正式,框架肯定是基于 LTS 开发,然而下个 LTS 版本是 2 年后了,也就是 2025 年 9 月。又是几年过去了。

不过,很巧的是,2025 年正好是 Java 的 30 岁( 1995 年开始算),希望到时候 30 而立的 Java 正能立起来吧。

6975 次点击
所在节点    Java
42 条回复
byte10
2023-06-21 10:12:59 +08:00
@franklinre webflux 这种风格挺奇怪的,如果单纯是为优化异步回调地狱的问题,那么用虚拟现场就可以解决掉。如果是用于解决其他的场景,那还是可以继续用的。它这种设计模式还是挺有意思的,它应该跟虚拟线程结合一起使用,解决异步问题,又能使用上 响应式的设计模式。
yazinnnn
2023-06-21 10:23:43 +08:00
回调地狱是地狱, monad 地狱也是地狱

loom 革不了 reactive 的命

两者打算解决的问题根本不一样

loom 主要是解决 bio 阻塞线程的问题, reactive 主要解决伸缩性和松耦合的问题
pengjl
2023-06-21 10:24:23 +08:00
不得不说,我现在还是在使用 1.8
windyboy
2023-06-21 11:00:13 +08:00
java 最近感觉强的地方是 graalvm
直接变成可执行二进制
Narcissu5
2023-06-21 11:02:31 +08:00
@mmdsun .net 最早引入 async/await 的时候也就是在同步方法外就了个 Async 结尾的异步方法,不会有多大的兼容性问题。async/await 的最大问题是侵入性太强,这东西从实现的角度说不难,java 一直不跟进就是觉得不够优雅
hello2090
2023-06-21 11:06:23 +08:00
单位电脑 i5-9500 8G 内存,跑得动 java21 吗?
Masoud2023
2023-06-21 11:13:47 +08:00
你说得对
offswitch
2023-06-21 11:15:45 +08:00
@hello2090 这跟 java21 没关系,你的工具的问题,做开发大概率不够,现在 16G 起步,32G 最好。
t6gfx4ddv3
2023-06-21 11:23:37 +08:00
我用 kotlin 用得挺好的,语法不大改我是没动力回 java 了,太繁琐了
diagnostics
2023-06-21 14:13:39 +08:00
@byte10 reactive 核心感觉还是 backpressure 能力
diagnostics
2023-06-21 14:16:57 +08:00
@windyboy 初看好像也很强,实际上抛弃了 Java 多平台的特性,而且 AOT 性能不一定有 JIT 强,Java 只是初始化的延迟较高,用 Azul 的 ReadyNOW 也能解决
dqzcwxb
2023-06-21 14:25:44 +08:00
特性越多不是更难以升级吗?最好升级的是兼容旧版本且无太多外在 api 才对吧
试想一下,如果虚拟线程需要你强制更新代码实现和调用才能使用那才是大部分人会放弃升级的理由
而目前虚拟线程仅仅只需要替换线程池实现而已,这个升级成本可以简化到一行代码但是可以提升 io 密集型任务性能更好的压榨 cpu 这样升级才是简单低成本吧?
dragondove
2023-06-21 15:41:53 +08:00
如果不管语法,java 其实主要被诟病的也就是运行时吃内存了,虽然 aot 编译能解决大部分,但是 aot 编译的成本可不低,超大的内存占用,超长的编译时间,而且性能也更差,不符合当前企业需求的场景。我个人对 java 更期待的是 project valhalla 和 project panama ,valhalla 项目实现后可以降低很多的内存占用(特化泛型来支持基础类型泛型,还有数值类之类的功能)(貌似还有一个 jep 在优化对象头大小的)。panama 的话主要是方便调用 cpp ,这样接入一些 ai 的生态会方便很多。(当然,我作为 linux wayland 桌面用户,更迫切的需求是 wakefield https://openjdk.org/projects/wakefield/ )
希望 java 越来越好
karottc
2023-06-21 16:52:12 +08:00
@mmdsun 我用 springboot2.7 试了一把,也可以用,而且非常强,太棒了。
byte10
2023-06-21 17:04:41 +08:00
@diagnostics backpressure 问题,用虚拟线程应该不存在了把,直接阻塞了😂
diagnostics
2023-06-21 17:27:39 +08:00
@byte10 #35 对于 Server 端应用呢?考虑 Servlet 的场景,为每个 session 创建一条线程,最大能接多少链接呢?这里设置一个固定值不可靠的,因为你设置大了,背后的 DB 的瓶颈在哪里,设置小了,utilization 不够了。

另外 Fibers 本质上我看文档感觉其实也就是个在线程池上虚拟各种东西,相比于 Reactive 只是:

1. API 简化了
2. 底层用了 OS 级别的 interrupt 支持?我感觉又不像
byte10
2023-06-21 18:42:40 +08:00
@diagnostics 你考虑的也是有点道理。DB 那边还是 要支持高并发的数据库才行
ysy950803
2023-06-21 19:08:02 +08:00
Java 估计还是历史包袱的缘故,想实现个语法糖都这么难,看看 Kotlin 的协程,真的人性化且简洁易懂,尤其是搞 Android 的话,早点用 Kotlin ,节约时间珍惜生命。
james122333
2023-06-21 22:47:52 +08:00
@diagnostics

然而 jar 包随便拿个 decompiler 东西就见光了 XD
james122333
2023-06-21 22:55:22 +08:00
云厂商每天都在偷笑有那么多程序可以参考

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://www.v2ex.com/t/950472

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX