这波 jdk21 的更新，会不会引发 go 系统重构成 Java 的 kpi 需求
assiadamo · 2023-09-21 11:45:35 +08:00 · 7642 次点击这是一个创建于 427 天前的主题，其中的信息可能已经有所发展或是发生改变。
来自一个老 javaer 的妄想 正经的： 有没有 java virtual thread 与 goroutine 的性能比较？
第 1 条附言 · 2023-09-21 14:47:26 +08:00
搜了一个报告
https://juejin.cn/post/7113736410598735903
Java8 占比 37%，Java11 占比 29%，甚至有 12%的被调查者使用了高于 Java12 的版本。
https://juejin.cn/post/7113736410598735903
Java8 占比 37%，Java11 占比 29%，甚至有 12%的被调查者使用了高于 Java12 的版本。
 |
1
darkengine 2023-09-21 11:56:32 +08:00  15
jdk8 的都不愿意升级到 21 ，为啥 go 要重构到 jdk21 🙄
|
 |
2
Breacher 2023-09-21 12:32:02 +08:00 via iPhone
我觉得并不会，Java 与 Go 之间的不同不仅仅在 Java 是否有一个跟 Go 的 goroutine 相对等的 java virtual thread 。它们在语法，学习曲线，依赖管理，工程化，实施部署，向后兼容性，生态，云原生支持等各方面都存在巨大差异。
|
 |
3
DefoliationM 2023-09-21 12:33:55 +08:00
没可能，一个 jvm 就劝退了。
|
 |
4
liuguang 2023-09-21 12:35:39 +08:00
就 java 那内存占用，谁会抛弃轻量级的选老古董。
|
 |
5
me1onsoda 2023-09-21 12:37:36 +08:00
等 Java8 boy 升级再说😁
|
 |
6
dc2002007 2023-09-21 12:59:13 +08:00
你的脑回路很清奇
|
 |
7
coer 2023-09-21 13:00:04 +08:00
有个疑问，就一个 virtual thread 不行吧，java 里面很多库的 io 会阻塞线程，不就把虚拟线程阻塞了？
|
 |
8
ixiaohei 2023-09-21 13:03:06 +08:00
@coer 这个 jdk 为了支持虚拟线程把以前阻塞 api 的都兼容虚拟线程了，现在会挂起虚拟线程，而不会阻塞系统线程了。不过我估计有些使用 native 操作系统调用的就不行了。
|
 |
9
BBCCBB 2023-09-21 13:03:35 +08:00
@coer socket 这些支持虚拟线程. 阻塞的时候就切走了, 等待唤醒. 都是阻塞的话 virtual thread 和线程就没区别了..
|
 |
10
kuituosi 2023-09-21 13:10:39 +08:00 via Android
主要是 native 那个会跟 go 竞争，而不是协程。而且 JAVA 的当前目标就是云原生
|
 |
11
mightybruce 2023-09-21 13:16:32 +08:00 1
go 又不是靠业务发展的，靠的是中间件和云原生。java 再怎么样，在云原生中也是靠边站的角色。只有少数云原生中间件会选用 java, 云原生大多数组件也不是一种语言，go/rust/c++ 三种都有。
|
 |
12
drvDPqg5nO7kZWhv 2023-09-21 13:17:04 +08:00 3
.NET 平台是目前为止唯一一个同时实现了 Green Thread 和 async/await 异步模型的平台，其 Green Thread 异步模型目前性能比 async/await 模型低一点，同时在与某些特定特性如线程局部静态变量和本机线程状态交互时存在功能上的问题，thread local 变量的支持以及暴露 native thread 状态变得非常难以实现。
https://github.com/dotnet/runtimelab/issues/2398 |
|
13
mightybruce 2023-09-21 13:19:05 +08:00 1
goroutine 不需要任何包，是直接嵌入 go 的，绝大多数性能比较的测试都是没有意义的。javaer 还是做你的 crud 还有业务吧，别来搞基础设施。
|
 |
14
vgbw 2023-09-21 13:20:08 +08:00
不太可能，goroutine 已经和 go 语言深度绑定了. java 的 virtual thread 是新增的特性，而且在运行 synchronized 代码块上还有阻塞的问题，很多库和框架还要做适配
|
|
15
mightybruce 2023-09-21 13:20:51 +08:00
goroutine 不是 coroutine 协程，GMP 调度 是多个线程对应多个协程的抢占式调度。async/await 是偏向 IO 的协程。
|
 |
16
liprais 2023-09-21 13:23:25 +08:00
一说 java
.net 神教闻着味就来了 |
 |
17
helone 2023-09-21 13:26:15 +08:00 4
要按你这个说法 .NET 早就🔥到天上去了
|
|
18
drvDPqg5nO7kZWhv 2023-09-21 13:31:03 +08:00
是很多 javaer 不懂异步，所以连 21 都不敢用，更别提 async await
|
 |
19
assiadamo OP @mightybruce 想起几年前面试 go 的时候，面试官还跟我争论过抢占式调度还是协作式调度，当时的 go 版本已经是抢占式了，他们也是老版本的不升级
|
 |
20
mmdsun 2023-09-21 13:40:17 +08:00
@coer 搜索了一下，为实现 virtual thread ，JDK 确实重写了大量代码包括 java.io 、java.net 、java.nio.channels 等包。
https://www.infoq.com/news/2023/04/virtual-threads-arrives-jdk21/ |
|
21
mmdsun 2023-09-21 13:42:28 +08:00
@guilinxiaobing
" Green Thread 异步模型目前性能比 async/await 模型低一点"，.NET 没像 Java 那边重写，JDK 实现虚拟线程重写了大量阻塞的代码。 |
|
22
assiadamo OP |
 |
23
Leviathann 2023-09-21 13:44:43 +08:00
@guilinxiaobing kotlin on JVM 一样同时使用有栈协程和无栈协程
|
|
24
assiadamo OP 1
@mightybruce 在“KPI 需求”上，大量的业务从其它语言迁移到 go ，也只是 curd 的级别而已
|
|
26
assiadamo OP @Breacher 是的，用惯了 java 通信层框架 netty ，看到 golang “pretty trivial Networking-101 stuff”，脑子确实是懵的
不过 java21 也能那样写了 |
 |
27
dif 2023-09-21 13:51:13 +08:00
感觉到我退休的时候，Java21 占比能不能到现在 11 那么多，咱就不比 8 了。
|
 |
28
qiyilai 2023-09-21 13:51:24 +08:00
确实是幻想
|
|
29
mmdsun 2023-09-21 13:55:59 +08:00
@guilinxiaobing
参考： https://www.infoq.com/articles/java-virtual-threads/ Java 语言架构师的文章，解释过为什么不用 async/await 模型和该模型的弊端。 虚拟线程不仅仅是异步框架的语法糖，而是对 JDK 库进行了彻底重构，而且不会有 async/await 颜色函数问题，更重要的是对开发者友好，改动非常小，而且与之前 Thread 兼容。 Java 现在主流还是 steam 异步流 +ComputableFuture 写起来也很简单，以后会增加 StructuredTaskScope 等结构化并发 API 。 |
|
30
drvDPqg5nO7kZWhv 2023-09-21 13:56:04 +08:00
世界在变化，java 也在变化，唯独 javaer“问今是何世，乃不知有汉”
|
 |
32
Navee 2023-09-21 14:00:47 +08:00
会引发升级到 spring boot3 ，jdk21 的 kpi 需求
|
 |
33
fy 2023-09-21 14:02:30 +08:00
能降降内存吗？然后 native 能好用点吗，编译一个东西尝逝了两天然后运行时候跟原本行为不一样失败了
|
 |
34
xiaocaiji111 2023-09-21 14:18:09 +08:00
不行，选型什么语言，又不单单看性能，而且决定权大部分时候不在程序员手里。很多企业还在用 jdk1.7 甚至 1.6 呢。java 强的是生态，各种业务中间件，大数据相关的，还有一统天下的 Spring 等等。云原生相关的组件，尤其是网络相关的基本都用 go 或者 c++了。相互配合吧，一个写业务爽，一个写基础设施爽。
|
 |
35
43n5Z6GyW39943pj 2023-09-21 14:20:17 +08:00
所以你用 java 几,很明显生产环境不会有什么变动
|
 |
36
sadboy2007 2023-09-21 14:37:34 +08:00
@mmdsun 学到了
|
 |
38
MapHacker 2023-09-21 14:54:45 +08:00
等 native 啥时候可用了再说吧
|
 |
39
c2const 2023-09-21 15:49:36 +08:00
虽然用 java 不多，但我倒是很期待 java 的 native 编译少点报错、兼容、版本等问题，并且在 IDEA 中的便捷性可以做到和正常 java 代码打个 jar 包一样简单。
|
 |
40
kkk9 2023-09-21 15:51:59 +08:00
讨论这种和讨论下一个风口是异曲同工啊
|
 |
41
winglight2016 2023-09-21 16:37:52 +08:00
为啥会用 java 做 native 开发？这需求就很怪。。。完全不符合 java 的定位啊
|
 |
42
idealhs 2023-09-21 16:54:39 +08:00
@liprais #16
在 5 小时内，在一个 40 多个回复的，讨论 JDK 在线程方面的更新是否可能与 Go 产生竞争的帖子中，有且仅有一个回复技术性地讨论了.NET 在异步方面的优点与不足。被 @liprais 概括为.NET 神教闻着 JAVA 的味就来了，确实很能体现 @liprais 的优秀素质与高超的 JAVA 编程水平。 |
|
43
liprais 2023-09-21 17:33:02 +08:00
@idealhs 你是第二个上钩的，直钩都咬还说不是.net 神教，咋地传教还打狼来一群才叫传教啊
|
|
44
fy 2023-09-21 19:08:53 +08:00 1
@assiadamo 我弄个小服务给别人跑，凭什么上来要我装一坨 jre ，有两年 jre 下载还特别难找要注册账号之类。 看看 JB 家的 IDE 那是个个自带 jre ，不同的 jre 和不同平台的 jre 也并不是真的完全一样能互相兼容。
我就希望体积小一点，然后 30mb 内存搞定。java 再小的程序带上 jre 压缩完都差不多 50mb 开外，一上来就吃大概 200mb 内存。 一次编译是真的，运行是哪儿都运行不了 |
 |
45
reeco 2023-09-21 19:10:47 +08:00
@guilinxiaobing 唯一一个？井底之蛙胡说八道啥呢
|
 |
47
xuanbg 2023-09-21 19:15:55 +08:00
你想多了，最少还得过 5 年，才有可能会有 go 改 java 。
|
|
48
mightybruce 2023-09-21 22:44:28 +08:00
另外说一句， 就算 java 有了这些其他语言早就有的，graalvm 不成熟稳定吧，java 打包二进制体积，启动速度提升依然都还早。新技术要求语言的新功能和特性，java 一个都没有。这几年业界关注的
都是语言有库集成 ebpf, 语言整合 wasm 配合 wasi 运行时。 |
 |
49
haha512 2023-09-22 00:28:48 +08:00
用 go 来写业务的，有可能也有价值转 java21 ，其他的没啥转的意义。go 用来写业务怪怪的，开发效率不如 java
|
 |
50
netabare 2023-09-22 06:12:05 +08:00 1
virtual thread 又不是 coroutine 。
锁神教的教徒们还是会继续上锁，然后把 carrier 干废。 重构吧……恭喜你重新发明了响应式编程。 拿头跟原生支持异步模型的语言比。 |
 |
51
BaseException 2023-09-22 08:48:59 +08:00
说 java8 升级到 java21 的，应该主要是针对老项目吧？
老项目的维护，一般企业都会选择维持版本吧，好端端的屎山能跑就行，升级之后还可能出现更多问题。但是鼓励开发者在新项目上尝试新 jdk 是很有必要的。我就是有老项目 java8 ，新项目 java17 ，前年和去年也有项目是 java11 的。 |
 |
52
fluyy 2023-09-22 08:53:17 +08:00 via iPhone
我为什么写 go ，简单啊。当年就觉得 java 写代码太啰嗦了。
|
 |
53
joyhub2140 2023-09-22 09:19:38 +08:00 2
两者的业务思路逐渐区分开来了
go 主要是写中间件，基础设施，主战场在云原生那里，最典型的应用就是 docker 了。 Java 因为其啰嗦的静态语言特性，适合写大型业务系统，主战场在业务那里，兼顾开发效率和性能，而且需求量不是 go 能比的。。业务系统拖一个 200MB 的 JDK 完全小 case 。。但一个中间件/基础设施的包就要拖一个 jdk 的确是蛋疼，这也是 go 的天然优势。 用哪个还是看自己主打方向。 |
 |
54
malukuan 2023-09-22 17:58:05 +08:00
業務地盤都保不住了， 別想著動 GO 的樂，VT 本就是為了兼容舊代碼而妥協的產物，性能連 reactive 都比不上。
|
 |
55
buffzty 2023-09-22 22:14:46 +08:00
对我来说 java 最大的问题是内存.go 启动一下 10m 占用. java 启动 2G 算轻量.
|
Select Language