Java21 make Java great again

@diagnostics 还在 actor
Scala 都不整这个玩 fiber 了

@voidmnwzp #28 2.go func(){} 和 Thread.startVirtualThread(() -> {...}); 谁更简洁一目了然

@voidmnwzp 提案上作者也说了，本来想用 go x()或 await/async 的方式，但为了让以前用 Thread API 的老程序受益，就直接改造 Thread 了，人家并不是不能更简化，人家是格局大！

@SuperManNoPain 介个怎么发音

我有个问题，既然虚拟线程不是真正的多线程。那我的数据库事务是不是都可以用同一个了

手里项目已经是 spring boot 3.1 + JDK 20 了， 坐等 JDK 21 更新

21 的虚拟线程解决 ThreadLocal 的问题了么？我记得好像是这个版本的还不支持 ThreadLocal 。

@yty2012g 支持 https://openjdk.org/jeps/444#Thread-local-variables

某国民级的游戏服务端刚刚从 7 升级到 8....

@totoro52 请教下是什么机制 go 有其它语言做不到的

@mgzu #36 感谢感谢。我们现在各种 wrap ExecutorSerivce 来传递各种各样的 ThreadLocal Context ，不知道换了还能不能生效了

@mgzu 这点就足够吊打 go 协程了

虚拟线程主要解决 io 密集型任务导致的线程数多(内存占用多)，上下文切换成本高问题。目前的上述问题的解决方案是 netty ，reactive 相关框架，但写法不直观。重点还是要发送请求的工具类也要支持非阻塞的。单纯使用虚拟线程，但 Java 的请求相关类没做改造的话，意义不大。

jdk21 出来的话，应该会推动很多类库更新

其实没用的，你看 C#，主流语言里第一个实现 async/await 协程的，也没见到增加多少使用者。
使用某一个语言，往往不是因为这个语言是否有哪些特性、是否优秀。更多的因素是政治和历史原因

@nikenidage1 中肯，感觉都是惯性

已经用了 kotlin 的无栈协程，性能提升非常好

go 的所有并发原语(mutex,channel)都是基于协程实现的,如果 jdk 单纯加了个虚拟线程，synchronized ,reenterLock 底层实现不变那也没啥意义,而且也不知道 jdk 的协程调度是否就比 go 的 gmp 高明

jdk 的 io 库 还是 bio 那套，要用 nio 就得上 netty ，但 netty 这种异步基于事件的处理模式远不如 go 通过协程包装的伪 bio 模式直观简单

你说的对，但是《 Java8 》是由 Oracle 自主研发的一款虚拟机。游戏发生在一个被称作「多线程」的幻想世界，在这里，被 jdk 选中的 Callable 将被授予「 CompletableFuture 」，导引线程之力。你将扮演一位名为「小公司程序员」的神秘角色只能在苦逼的编码中邂逅性格各异、能力独特的业务代码，和他们一起创造新屎坑，找回失散的劳动法同时，逐步发掘「异步」的真相。

@yazinnnn
现在 Java 高并发应该流行 Reactive Programming ？ ThreadLocal 不是什么好设计了吧？与反应式也完全不兼容。
spring 新框架 webflux 也是支持，用的是 Context 传递之和当前操作，只与 Flux 和 Mono 相关。

JDK9 也是新加了 Reactive Streams API 的支持，假设不用 spring webflux 单独用 Rxjava 和 Project Reactor 用链式操作符传递也够了。完全可以不用 ThreadLocal

还有个更好的消息，GraalVM 的免费版本增加了一个 Oracle GraalVM ，这个是完全免费使用，允许商业使用的。而且可以使用 EE 版本的很多功能，比如 PGO ，G1GC ，压缩指针。这些功能在开源的版本当中是没有的。

https://medium.com/graalvm/a-new-graalvm-release-and-new-free-license-4aab483692f5

我们内部有一个好几千人的活跃 slack channel ，讨论如何解决 service 在从 jdk8 migrate 到 17 当中出现的问题

@oldshensheep 能把多语言支持完全开源允许商用就好了

第一次看到虚拟线程的介绍就震惊了。虽然很期待，但是，用起来才是正道。

越是挣扎，越是真的要没落了。

@hhjswf 你在说什么，计算任务直接 new Thread 朴素平台线程就行了， 甚至线程池都不需要

@wangxiaodong #26
@TWorldIsNButThis #29

对对对，你俩是真懂。gRPC benchmark 里 scala-akka 去年还是前几，OP 说的变革，Fibers 能做的，actor 也能做个 80%，更不用说 VT 现在连线程公平性都没搞出来（ JEP-425 的时候）背后一大堆隐藏的性能 BUG 。

要讨论可以，先 follow up 行业知识再来，JEP-425 都没看完都指点江山了？

@seaiaddca 怎么加入呢？有没有啥电报群啊什么的

@yusheng88 #41 哥们你是懂得，帖内太多半桶水半吊子的指点江山了

@Morii 王者农药？

@diagnostics #58

第一版预览，jep425
https://openjdk.org/jeps/425

第二版预览，jep436
https://openjdk.org/jeps/436

正式版，jep444
https://openjdk.org/jeps/444

每一版都有些变化和改进。

还是 Kotlin 吧 别挣扎了

更关心 String Template, 可以愉快的用类似 python 的 f-string 方式写 String 了. 至于性能什么的, 小作坊的自行车没机会上高速

@HaroldFinchNYC

不是哈哈

@yangyaofei String Template 用这个，Java8 就能用，https://github.com/manifold-systems/manifold

https://github.com/manifold-systems/manifold/blob/master/manifold-deps-parent/manifold-strings/README.md

@oldshensheep 用过不是很好用, 最后用了 com.antkorwin:better-strings:0.5 , 但是也就那样, IDE 的支持也一般吧, 而且还需要构建环境上加上一堆设置.

@dreamramon 大佬看看有没空拉一帮同道去把那些库用 Java 整一下[坏笑]

@impossibleshen
没有 公司内部的 channel

virtual thread 目前 public 的 api 都太简单了，不如 kt 可以微操调度，所以我还搞了这个玩意 https://github.com/dreamlike-ocean/UnsafeVirtualThread ，来搞手操调度，指定调度器，捞 carrierThread
virtual thread 好处对我来说有两处:
1,是沟通 Reactive 到 Blocking 的桥梁，我可以低成本来复用老的 BIO 生态，比如我就喜欢开虚拟线程跑 jdbc+myabtis/hibernate,比 hibernate reactive 好用多了
2,我可以低成本将异步转同步，比如说 Future.await ，直接捞 continuation api 起来自己做调度也很好玩，对于 reactive 生态来说就无需引入 kotlin ，也无需被无栈协程的染色效应困扰

最近 java 最大的一个优化应该是推广 zgc, 10ms 以内.

@Morii 梦幻西游？

@Ericcccccccc zgc 话说这玩意代价不是减低吞吐么?还是说我 Out 了..最近这个代价也解决了?

@dbpe 吞吐降低不多，还有监控时都懂三倍内存问题，不好解决

@javak #74 jdk21 要上 zgc 分代并取消多重映射,三倍内存的问题就没了

@dqzcwxb 太棒了，我要去研究下分代 zgc 了

现在 99%的线程池的确可以用虚拟线程代替，尤其是是 web 应用，大量下游各种调用的。
一些老框架会焕发青春，比如一些用 netty 改造的 client ，有了虚拟线程就没这个必要了就直接用线程池+同步代码就可以。
还有就是大部分 reactive 场景其实都是不需要的，改回同步代码即可

可惜屎山迭代的难度不亚于重写了

相比这个，我更喜欢的还是终于要有语言层面的 nullability 了，kotlin 我唯一喜欢的 feature 。以后就不用写 @Nullable 注解了

https://mail.openjdk.org/pipermail/valhalla-spec-experts/2023-May/002276.html

@dbpe 官方的宣传是大多数时候 stw 时间能控制在 1ms 以内, 并且和堆大小无关.

@acapla 这就是我的愿望了，有些新的东西不是胡说就是提示训练集只到 2021 年

我也一直在等正式版发布，我在自己本地已经在用早期版本了，不过最新的早期版本 jdk21-ea-27 ，在我的社区版的 idea 有个 bug ，timeunit 这个类识别有问题。

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

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


我的本地脚本任务用虚拟线程爽的飞起，因为我经常需要帮老板从 cdn 上下载几十万的音频和图片，现在这个任务直接起飞。

其他生态跟不上没啥用

@Morii #37

搜了下相关文章，感觉。。开心消消乐？

王者荣耀这种肯定不适合用 java 。。

@zhouquanbest kotlin 协程最大的问题是生态，一旦调用的库用到了阻塞 IO ，性能马上退化到和传统 Java 线程池一个水平了

@dif #83 说出这话就说明你其实根本就没细看过,虚拟线程没有新增关键字只需要替换下线程池实现即可对旧代码非常友好,甚至框架或者组件如果本身就支持线程池替换的话连包都不用重新发,开发者(我们)把线程池替换一下就完事了
需要关注的是 sync threadlocal 以及大量虚拟线程中创建的对象,但是这些会在 jdk21 中进行优化和处理

@karottc #82 你可以试试用 forkjoin 线程池去跑你的任务,我预计应该效果差不多

@kenvix 所以虚拟线程对 kotlin 也是利器，阻塞的调用可以用 virtual thread dispatcher

@Ericcccccccc #71 实际上是承诺 stw 在 1ms 内 实际平均是 0.05ms
zgc 目前的吞吐下降和三倍内存问题会在 jdk21 推出 zgc 分代后得到优化和解决
jdk21 virtual thread 和 zgc 是性能提升大杀器,而且这两个对开发者非常友好可以做到开箱即用

@dqzcwxb 你大概没理解我意思。我的意思是我升级到 21 ，其他组件不支持这么高版本。例如我一直想升级到 java17 ，但 impala 驱动不支持（最高支持到 java11 ，我谢谢它，还好不是 java8 ），所以，java17 玩得再花，我也没办法升级。类似的场景有很多。

@Ericcccccccc #80 听起来非常像 C4 Garbage Collector

@javak #62 我的观点是，无论是 Fiber 还是 Reactive ，都是在简化多核编程的难度，但 Fibre 能保持 `thread-pre-request` style 的简单性，而 Reactive 更复杂，所以你觉得效果炸裂只是你没接触、用过 Reactive

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

所以 Java 21 不会发生多大的变革吧，Java 一直是蓝领语言，Java21 只能说终于跟上了时代的脚步

@diagnostics 同意啊，能跟上时代对我来说就是惊艳，就是那种不用换语言，用 Java 终于也能跟上时代了的感觉

@dif #90 我跟你说的又不冲突,你说的是不支持的情况,我说的是很多包不需要兼容就可以直接升级到 21 因为虚拟线程并没有破坏之前的线程相关 api 而是扩展和兼容
你有你的难处,但是这并不代表整个生态就会因为这个而停滞因为大部分都是可以无损升级的,只是你和部分人部分包会是个例,比如之前用 unsafe 的从 sun.misc 改到 jdk.internal.misc

@dqzcwxb 明白你得意思，你的维度指的是针对线程相关 API 可以无缝切换，例如 JDK1.7 的 hashmap 和 JDK1.8 的 hashmap ，虽然底层实现变了，但对外 API 没变化。
我的维度是，我想用这个东西，可惜一些历史包袱只能让我望洋兴叹。

synchronized 和 ThreadLocal 不解决没法推广到业务，尤其是 ThreadLocal 的隐患太大了，希望能快点搞定吧

@Aresxue 具体讲讲是啥问题，给个复现场景我去试试

我们这已经大部分应用都到 17 了，21 规划落地中