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

[assiadamo]

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

[mmdsun]

@guilinxiaobing
" Green Thread 异步模型目前性能比 async/await 模型低一点"，.NET 没像 Java 那边重写，JDK 实现虚拟线程重写了大量阻塞的代码。

[assiadamo]

@helone 感觉.NET 的问题不在语言，还是在系统兼容性上，我游戏行业的，也曾有过客户端用 c#写的游戏逻辑要在服务器跑验证，遇到过在 linux 跑不起来或者用 mono 跑起来了性能差一大截的问题，最后要单独开 windows server 执行，当然也可能是才疏学浅搞不定
听说现在.NET 在 linux 上的支持已经很好了，不知道有没有大规模的工业实践

[Leviathann]

@guilinxiaobing kotlin on JVM 一样同时使用有栈协程和无栈协程

[assiadamo]

@mightybruce 在“KPI 需求”上，大量的业务从其它语言迁移到 go ，也只是 curd 的级别而已

[yazinnnn]

@liprais 为啥不能来, 承认.net 比 java 好很难吗😋

[assiadamo]

@Breacher 是的，用惯了 java 通信层框架 netty ，看到 golang “pretty trivial Networking-101 stuff”，脑子确实是懵的
不过 java21 也能那样写了

[dif]

感觉到我退休的时候，Java21 占比能不能到现在 11 那么多，咱就不比 8 了。

[qiyilai]

确实是幻想

[mmdsun]

@guilinxiaobing

参考： https://www.infoq.com/articles/java-virtual-threads/

Java 语言架构师的文章，解释过为什么不用 async/await 模型和该模型的弊端。
虚拟线程不仅仅是异步框架的语法糖，而是对 JDK 库进行了彻底重构，而且不会有 async/await 颜色函数问题，更重要的是对开发者友好，改动非常小，而且与之前 Thread 兼容。

Java 现在主流还是 steam 异步流 +ComputableFuture 写起来也很简单，以后会增加 StructuredTaskScope 等结构化并发 API 。

[guilinxiaobing]

世界在变化，java 也在变化，唯独 javaer“问今是何世，乃不知有汉”

[liprais]

@yazinnnn 啊对对对，我宣布.net 是世界上最好的语言行了吧

[Navee]

会引发升级到 spring boot3 ，jdk21 的 kpi 需求

[fy]

能降降内存吗？然后 native 能好用点吗，编译一个东西尝逝了两天然后运行时候跟原本行为不一样失败了

[xiaocaiji111]

不行，选型什么语言，又不单单看性能，而且决定权大部分时候不在程序员手里。很多企业还在用 jdk1.7 甚至 1.6 呢。java 强的是生态，各种业务中间件，大数据相关的，还有一统天下的 Spring 等等。云原生相关的组件，尤其是网络相关的基本都用 go 或者 c++了。相互配合吧，一个写业务爽，一个写基础设施爽。

[MorJS]

所以你用 java 几,很明显生产环境不会有什么变动

[sadboy2007]

@mmdsun 学到了

[assiadamo]

@fy 说好的一次编译到处运行呢

[MapHacker]

等 native 啥时候可用了再说吧

[c2const]

虽然用 java 不多，但我倒是很期待 java 的 native 编译少点报错、兼容、版本等问题，并且在 IDEA 中的便捷性可以做到和正常 java 代码打个 jar 包一样简单。

[kkk9]

讨论这种和讨论下一个风口是异曲同工啊