这波 jdk21 的更新，会不会引发 go 系统重构成 Java 的 kpi 需求

[assiadamo]

来自一个老 javaer 的妄想 正经的： 有没有 java virtual thread 与 goroutine 的性能比较？

[darkengine]

jdk8 的都不愿意升级到 21 ，为啥 go 要重构到 jdk21 🙄

[Breacher]

我觉得并不会，Java 与 Go 之间的不同不仅仅在 Java 是否有一个跟 Go 的 goroutine 相对等的 java virtual thread 。它们在语法，学习曲线，依赖管理，工程化，实施部署，向后兼容性，生态，云原生支持等各方面都存在巨大差异。

[DefoliationM]

没可能，一个 jvm 就劝退了。

[liuguang]

就 java 那内存占用，谁会抛弃轻量级的选老古董。

[me1onsoda]

等 Java8 boy 升级再说😁

[dc2002007]

你的脑回路很清奇

[coer]

有个疑问，就一个 virtual thread 不行吧，java 里面很多库的 io 会阻塞线程，不就把虚拟线程阻塞了？

[ixiaohei]

@coer 这个 jdk 为了支持虚拟线程把以前阻塞 api 的都兼容虚拟线程了，现在会挂起虚拟线程，而不会阻塞系统线程了。不过我估计有些使用 native 操作系统调用的就不行了。

[BBCCBB]

@coer socket 这些支持虚拟线程. 阻塞的时候就切走了, 等待唤醒. 都是阻塞的话 virtual thread 和线程就没区别了..

[kuituosi]

主要是 native 那个会跟 go 竞争，而不是协程。而且 JAVA 的当前目标就是云原生

[mightybruce]

go 又不是靠业务发展的，靠的是中间件和云原生。java 再怎么样，在云原生中也是靠边站的角色。只有少数云原生中间件会选用 java, 云原生大多数组件也不是一种语言，go/rust/c++ 三种都有。

[guilinxiaobing]

.NET 平台是目前为止唯一一个同时实现了 Green Thread 和 async/await 异步模型的平台，其 Green Thread 异步模型目前性能比 async/await 模型低一点，同时在与某些特定特性如线程局部静态变量和本机线程状态交互时存在功能上的问题，thread local 变量的支持以及暴露 native thread 状态变得非常难以实现。
https://github.com/dotnet/runtimelab/issues/2398

[mightybruce]

goroutine 不需要任何包，是直接嵌入 go 的，绝大多数性能比较的测试都是没有意义的。javaer 还是做你的 crud 还有业务吧，别来搞基础设施。

[vgbw]

不太可能，goroutine 已经和 go 语言深度绑定了. java 的 virtual thread 是新增的特性，而且在运行 synchronized 代码块上还有阻塞的问题，很多库和框架还要做适配

[mightybruce]

goroutine 不是 coroutine 协程，GMP 调度 是多个线程对应多个协程的抢占式调度。async/await 是偏向 IO 的协程。

[liprais]

一说 java
.net 神教闻着味就来了

[helone]

要按你这个说法 .NET 早就🔥到天上去了

[guilinxiaobing]

是很多 javaer 不懂异步，所以连 21 都不敢用，更别提 async await

[assiadamo]

@mightybruce 想起几年前面试 go 的时候，面试官还跟我争论过抢占式调度还是协作式调度，当时的 go 版本已经是抢占式了，他们也是老版本的不升级

[mmdsun]

@coer 搜索了一下，为实现 virtual thread ，JDK 确实重写了大量代码包括 java.io 、java.net 、java.nio.channels 等包。

https://www.infoq.com/news/2023/04/virtual-threads-arrives-jdk21/