JDK21 9 月 19 日 来咯！

[forschers]

Visual Threads （虚拟线程）来了，终于可以把 8 换了。

[Weixiao0725]

21 是 LTS 吗

[zhaojames077]

是 Virtual Threads 吧

[nikenidage1]

他强任他强，清风拂山岗；他发由他发，我用爪哇八

[Subfire]

https://jdk.java.net/21/
21 General Availability 还不能下载吧?

[forschers]

最大程度的提升硬件利用率

[forschers]

@zhaojames077 我搞错了

[8355]

还是 java8 没用的 耶稣来了都改不了

[banmuyutian]

@Weixiao0725
应该是

[forschers]

@8355 哈哈哈该换换

[forschers]

好多年了

[putaozhenhaochi]

8 该换了吧

[forschers]

@putaozhenhaochi 感觉可以换了 虚拟线程能大幅度提升硬件利用率

[adonislau]

不是 22 么？

[chocotan]

看下载地址，已经 GA 了，只是页面还没换

[forschers]

@adonislau 不是

[jamosLi]

不打扰我用 1.8

[chuck1in]

21 是 lts 么。

[mmdsun]

@nikenidage1 之前看统计报告 java 8 现在用的人少了，还没 Java 11 多。

[cbdyzj]

@chuck1in 是 LTS

[Subfire]

@chocotan 为啥我这看的还是 Release-Candidate https://jdk.java.net/21/

[Aresxue]

生产还是 java8 ，太难升了，比如你依赖的单点登录的 client 是 1.8 吧不支持 11 你怎么推动别人改造
可以看看这篇 为什么很多公司选择不升级 JDK 版本，仍然使用 JDK8 ？ - 君莫惘的回答 - 知乎
https://www.zhihu.com/question/325293339/answer/1150270157

[zhouxelf]

公司部分核心项目已经提前升级到 20 了，就等 21 出了

[ychost]

依赖的中间件都是 Netty + AIO 回调，这个 Loom 没法优化吧

[kenvix]

@ychost Netty + AIO 回调这种优化收益也不大。收益大的是线程池+阻塞 IO 的

[zhouhu]

分代 ZGC 据说性能很强

[Goooooos]

虚拟线程对于 ThreadLocal 有优化支持吗？

[zhouhu]

我看到油管的信息，分代 ZGC 吞吐量是 ZGC 的四倍，堆大小是 ZGC 的五分之一，很期待。

[Mirage09]

笑死 我们刚 migrate 到 11

[ychost]

@kenvix 阿里内部也有 wisp2 支持 JDK8 ，也是个有栈协程，除了中间件再用，业务团队用的比较少

[zhouhu]

@Goooooos https://openjdk.org/jeps/444

irtual threads support thread-local variables (ThreadLocal) and inheritable thread-local variables (InheritableThreadLocal), just like platform threads, so they can run existing code that uses thread locals.

没看到说有优化

[zhouhu]

@Mirage09 升级到 11 了，据说后面再升级就容易了。

[coobbi]

估计得明天，美国慢了 12 个小时

[zhouhu]

@Goooooos
JEP 446 Scoped Values (Preview)
Introduce scoped values, values that may be safely and efficiently shared to methods without using method parameters. They are preferred to thread-local variables, especially when using large numbers of virtual threads. This is a preview API.

[neptuno]

大概几点出来啊，好像没看到下载

[GuardX]

https://jdk.java.net/archive/

[GuardX]

没看到有 GA 版本呀

[somebody]

这篇文章可以再翻出来看看了：

甲骨文 Java 语言架构师：虚拟线程将会深刻影响大规模 Java 应用的并发机制
作者 | Brian Goetz （ Architect for the Java Language, Oracle Corporation ）

https://mp.weixin.qq.com/s/mCMxVKjaaXhSHyGtMyn46g

[iblessyou]

想用打包为 exe 的功能，得 jdk17 ，要下 vs ，搞了 2 小时没成功，继续玩 8……

[giter]

https://openjdk.org/jeps/444

[FallenTy]

新项目有机会升，老项目继续祖宗之法。

[bjfane]

@iblessyou java 项目打包到“exe”，之前试过，这个 exe 和理解的 exe 不完全是一个东西，
比如加了类似“数据库连接池”（具体加什么都不能打忘记了），就没法打了，
总结就是算是语言行，但是不是所有项目都行，看用到了什么

[leisifung]

@Weixiao0725 是的。

[eatgrass]

继续玩 J8

[just4id]

转 Rust 了，不淌这浑水

[me1onsoda]

@bjfane 没关系啊，总不会有人希望把一个 web 服务打成 exe 在 Windows 上跑?

[natsu94]

感谢 spring boot 3 ，我司主营业务已经升级到 17 了

[Breadykid]

虚拟线程是为了高吞吐，
并且习惯开一个线程池来操作的方式需要改为信号量操作，对已有功能升级还是需要代码改动的，
有高吞吐需求的新功能可以试试，在有栈协程中性能较优
https://openjdk.org/jeps/444 中有完整说明

[iblessyou]

@bjfane 这个能不能 exe 同目录，像 jar 一样放个配置文件，然后默认读这个配置文件。

[lokig]

这是一个大杀器，8 升级终于找到理由了。8 到 21 中间那些版本相比之下，就是小修小补

[bjfane]

@iblessyou 还真没试那么细，看起来读一个配置文件应该没啥问题。
@me1onsoda 我还真是想把一个 api 服务弄成一个 exe 随便到处无依赖传递 ：）

[suxixi]

native 才是未来啊

[lokig]

oracle 官网已经可以下载了
https://www.oracle.com/java/technologies/downloads/

[laojin]

JDK 21 is the latest long-term support release of Java SE Platform.

[QWE321ASD]

一直有人说不好升级,排除中间件依赖的包改名或者移除的问题,模块化也没那么麻烦啊,更何况有类路径模式,即不创建 module-info 的用法,这种用法和用 jdk8 用着几乎没有区别

[voidmnwzp]

1.国内不会用 jdk8 以外的版本
2.同步原语没用协程重写，所以然并卵

[fox0001]

终于来了，但是要等各方面的跟进…

[forschers]

@lokig 阶段性飞跃

[nnegier]

java21 可以跑 java8 的字节码吗？

[mmdsun]

@nnegier
@Aresxue
“比如你依赖的单点登录的 client 是 1.8 吧不支持 11 你怎么推动别人改造”

你项目 jdk 21 引入 jdk 8 的依赖也能编译通过，maven 也能配置

[Subfire]

终于 GA 了, https://jdk.java.net/21/

[Aresxue]

@mmdsun 真这么简单早升级完了，光 JPMS 和反射的限制就够喝一壶的，更别提原有的 java agent 可能都要失效了，我手上的项目 100 多个应用，2000 多个 pod ，要真到 21 没个两年下不来。

[zhouhu]

@voidmnwzp
你说的是这个吧
There are two scenarios in which a virtual thread cannot be unmounted during blocking operations because it is pinned to its carrier:

When it executes code inside a synchronized block or method, or
When it executes a native method or a foreign function.

官方解释：
The scheduler does not compensate for pinning by expanding its parallelism. Instead, avoid frequent and long-lived pinning by revising synchronized blocks or methods that run frequently and guard potentially long I/O operations to use java.util.concurrent.locks.ReentrantLock instead. There is no need to replace synchronized blocks and methods that are used infrequently (e.g., only performed at startup) or that guard in-memory operations. As always, strive to keep locking policies simple and clear.

后续优化：
In a future release we may be able to remove the first limitation above, namely pinning inside synchronized. The second limitation is required for proper interaction with native code.

[arloor]

@zhouhu pin 是什么意思

[zhouhu]

@arloor
some blocking operations in the JDK do not unmount the virtual thread, and thus block both its carrier and the underlying OS thread.

If a virtual thread performs a blocking operation such as I/O or BlockingQueue.take() while it is pinned, then its carrier and the underlying OS thread are blocked for the duration of the operation. Frequent pinning for long durations can harm the scalability of an application by capturing carriers.

[Subfire]

为啥换成 JDK21 后,
import java.util.concurrent.TimeUnit;
这个都报错

[javaZhenJuan]

@Subfire 我的也报错