Java21 make Java great again

2023-06-16 08:21:18 +08:00
 javak

今天用了下 oracle 放出来的 Java21 早期版本,( Java21 正式版要今年 9.19 发布)。

主要是为了测试虚拟线程( Java21 开始虚拟线程就是正式版了),这是是一个类是 go 协程的东西。

我搞了 100 万个任务,每个任务一个线程模式,效果非常惊艳炸裂。cpu 、内存消耗非常稳定,也不高。相同情况用 Java 之前的普通线程( Java21 开始叫平台线程)试了下,吞吐完全不行,而且 CPU 、内存占用很高、起伏也很大。

上面只是随手简单一测,并不严格和规范。但是效果我觉得还是能说明问题,那就是很强、很惊艳。我认为现在已经算是可以追平之前 go 吹爆的 go 协程特性了。

所以就有了标题的感慨。

10989 次点击
所在节点    Java
98 条回复
winterbells
2023-06-17 07:52:31 +08:00
@acapla 这就是我的愿望了,有些新的东西不是胡说就是提示训练集只到 2021 年
karottc
2023-06-17 09:39:43 +08:00
我也一直在等正式版发布,我在自己本地已经在用早期版本了,不过最新的早期版本 jdk21-ea-27 ,在我的社区版的 idea 有个 bug ,timeunit 这个类识别有问题。

https://youtrack.jetbrains.com/issue/IDEA-321080

不知道是 oracle 的问题还是 idea 的问题。除了这个别的都很好,而且 zgc 的三倍内存问题已经解决了。


我的本地脚本任务用虚拟线程爽的飞起,因为我经常需要帮老板从 cdn 上下载几十万的音频和图片,现在这个任务直接起飞。
dif
2023-06-17 09:47:57 +08:00
其他生态跟不上没啥用
flyqie
2023-06-17 10:28:29 +08:00
@Morii #37

搜了下相关文章,感觉。。开心消消乐?

王者荣耀这种肯定不适合用 java 。。
kenvix
2023-06-17 12:07:51 +08:00
@zhouquanbest kotlin 协程最大的问题是生态,一旦调用的库用到了阻塞 IO ,性能马上退化到和传统 Java 线程池一个水平了
dqzcwxb
2023-06-17 12:28:23 +08:00
@dif #83 说出这话就说明你其实根本就没细看过,虚拟线程没有新增关键字只需要替换下线程池实现即可对旧代码非常友好,甚至框架或者组件如果本身就支持线程池替换的话连包都不用重新发,开发者(我们)把线程池替换一下就完事了
需要关注的是 sync threadlocal 以及大量虚拟线程中创建的对象,但是这些会在 jdk21 中进行优化和处理
dqzcwxb
2023-06-17 12:29:22 +08:00
@karottc #82 你可以试试用 forkjoin 线程池去跑你的任务,我预计应该效果差不多
Leviathann
2023-06-17 12:30:35 +08:00
@kenvix 所以虚拟线程对 kotlin 也是利器,阻塞的调用可以用 virtual thread dispatcher
dqzcwxb
2023-06-17 12:37:46 +08:00
@Ericcccccccc #71 实际上是承诺 stw 在 1ms 内 实际平均是 0.05ms
zgc 目前的吞吐下降和三倍内存问题会在 jdk21 推出 zgc 分代后得到优化和解决
jdk21 virtual thread 和 zgc 是性能提升大杀器,而且这两个对开发者非常友好可以做到开箱即用
dif
2023-06-19 11:18:59 +08:00
@dqzcwxb 你大概没理解我意思。我的意思是我升级到 21 ,其他组件不支持这么高版本。例如我一直想升级到 java17 ,但 impala 驱动不支持(最高支持到 java11 ,我谢谢它,还好不是 java8 ),所以,java17 玩得再花,我也没办法升级。类似的场景有很多。
diagnostics
2023-06-19 11:34:39 +08:00
@Ericcccccccc #80 听起来非常像 C4 Garbage Collector
diagnostics
2023-06-19 11:41:35 +08:00
@javak #62 我的观点是,无论是 Fiber 还是 Reactive ,都是在简化多核编程的难度,但 Fibre 能保持 `thread-pre-request` style 的简单性,而 Reactive 更复杂,所以你觉得效果炸裂只是你没接触、用过 Reactive

包括 ZGC 也是用 Azul C4 论文剩下的东西,俗称捡垃圾。

所以 Java 21 不会发生多大的变革吧,Java 一直是蓝领语言,Java21 只能说终于跟上了时代的脚步
javak
2023-06-19 12:09:45 +08:00
@diagnostics 同意啊,能跟上时代对我来说就是惊艳,就是那种不用换语言,用 Java 终于也能跟上时代了的感觉
dqzcwxb
2023-06-19 14:27:22 +08:00
@dif #90 我跟你说的又不冲突,你说的是不支持的情况,我说的是很多包不需要兼容就可以直接升级到 21 因为虚拟线程并没有破坏之前的线程相关 api 而是扩展和兼容
你有你的难处,但是这并不代表整个生态就会因为这个而停滞因为大部分都是可以无损升级的,只是你和部分人部分包会是个例,比如之前用 unsafe 的从 sun.misc 改到 jdk.internal.misc
dif
2023-06-19 17:31:01 +08:00
@dqzcwxb 明白你得意思,你的维度指的是针对线程相关 API 可以无缝切换,例如 JDK1.7 的 hashmap 和 JDK1.8 的 hashmap ,虽然底层实现变了,但对外 API 没变化。
我的维度是,我想用这个东西,可惜一些历史包袱只能让我望洋兴叹。
Aresxue
2023-06-20 10:42:06 +08:00
synchronized 和 ThreadLocal 不解决没法推广到业务,尤其是 ThreadLocal 的隐患太大了,希望能快点搞定吧
javak
2023-06-20 11:44:55 +08:00
@Aresxue 具体讲讲是啥问题,给个复现场景我去试试
BigMaMa123
2023-09-21 00:07:34 +08:00
我们这已经大部分应用都到 17 了,21 规划落地中

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

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

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

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

© 2021 V2EX