这是一个创建于 72 天前的主题，其中的信息可能已经有所发展或是发生改变。
Visual Threads （虚拟线程）来了，终于可以把 8 换了。
 |
1
Weixiao0725 72 天前
21 是 LTS 吗
|
 |
2
zhaojames077 72 天前
是 Virtual Threads 吧
|
 |
3
nikenidage1 72 天前  13
他强任他强，清风拂山岗；他发由他发，我用爪哇八
|
 |
4
Subfire 72 天前
https://jdk.java.net/21/
21 General Availability 还不能下载吧? |
 |
5
forschers OP 最大程度的提升硬件利用率
|
|
6
forschers OP @zhaojames077 我搞错了
|
 |
7
8355 72 天前
还是 java8 没用的 耶稣来了都改不了
|
 |
8
banmuyutian 72 天前
@Weixiao0725
应该是 |
|
10
forschers OP 好多年了
|
 |
11
putaozhenhaochi 72 天前 via iPhone
8 该换了吧
|
|
12
forschers OP @putaozhenhaochi 感觉可以换了 虚拟线程能大幅度提升硬件利用率
|
 |
13
adonislau 72 天前
不是 22 么？
|
 |
14
chocotan 72 天前
看下载地址，已经 GA 了，只是页面还没换
|
 |
16
jamosLi 72 天前 2
不打扰我用 1.8
|
 |
17
chuck1in 72 天前
21 是 lts 么。
|
 |
18
mmdsun 72 天前
@nikenidage1 之前看统计报告 java 8 现在用的人少了，还没 Java 11 多。
|
|
20
Subfire 72 天前
@chocotan 为啥我这看的还是 Release-Candidate https://jdk.java.net/21/
|
 |
21
Aresxue 72 天前
生产还是 java8 ，太难升了，比如你依赖的单点登录的 client 是 1.8 吧不支持 11 你怎么推动别人改造
可以看看这篇 为什么很多公司选择不升级 JDK 版本，仍然使用 JDK8 ？ - 君莫惘的回答 - 知乎 https://www.zhihu.com/question/325293339/answer/1150270157 |
 |
22
zhouxelf 72 天前 2
公司部分核心项目已经提前升级到 20 了，就等 21 出了
|
 |
23
ychost 72 天前
依赖的中间件都是 Netty + AIO 回调，这个 Loom 没法优化吧
|
 |
25
zhouhu 72 天前
分代 ZGC 据说性能很强
|
 |
26
Goooooos 72 天前
虚拟线程对于 ThreadLocal 有优化支持吗？
|
|
27
zhouhu 72 天前
我看到油管的信息，分代 ZGC 吞吐量是 ZGC 的四倍，堆大小是 ZGC 的五分之一，很期待。
|
 |
28
Mirage09 72 天前 via iPhone
笑死 我们刚 migrate 到 11
|
|
30
zhouhu 72 天前
@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. 没看到说有优化 |
 |
32
coobbi 72 天前
估计得明天，美国慢了 12 个小时
|
|
33
zhouhu 72 天前
@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. |
 |
34
neptuno 72 天前
大概几点出来啊，好像没看到下载
|
 |
35
GuardX 72 天前
|
|
36
GuardX 72 天前
没看到有 GA 版本呀
|
 |
37
somebody 72 天前 via Android
这篇文章可以再翻出来看看了：
甲骨文 Java 语言架构师：虚拟线程将会深刻影响大规模 Java 应用的并发机制 作者 | Brian Goetz （ Architect for the Java Language, Oracle Corporation ） https://mp.weixin.qq.com/s/mCMxVKjaaXhSHyGtMyn46g |
 |
38
iblessyou 72 天前
想用打包为 exe 的功能，得 jdk17 ，要下 vs ，搞了 2 小时没成功，继续玩 8……
|
 |
39
giter 72 天前
|
 |
40
FallenTy 72 天前
新项目有机会升，老项目继续祖宗之法。
|
 |
41
bjfane 72 天前
@iblessyou java 项目打包到“exe”，之前试过，这个 exe 和理解的 exe 不完全是一个东西，
比如加了类似“数据库连接池”（具体加什么都不能打忘记了），就没法打了， 总结就是算是语言行，但是不是所有项目都行，看用到了什么 |
 |
42
leisifung 72 天前
@Weixiao0725 是的。
|
 |
43
eatgrass 72 天前
继续玩 J8
|
 |
44
just4id 72 天前 via iPhone
转 Rust 了，不淌这浑水
|
 |
46
natsu94 72 天前
感谢 spring boot 3 ，我司主营业务已经升级到 17 了
|
 |
47
Breadykid 72 天前
虚拟线程是为了高吞吐，
并且习惯开一个线程池来操作的方式需要改为信号量操作，对已有功能升级还是需要代码改动的， 有高吞吐需求的新功能可以试试，在有栈协程中性能较优 https://openjdk.org/jeps/444 中有完整说明 |
 |
49
lokig 72 天前
这是一个大杀器，8 升级终于找到理由了。8 到 21 中间那些版本相比之下，就是小修小补
|
 |
51
suxixi 72 天前
native 才是未来啊
|
|
52
lokig 72 天前
oracle 官网已经可以下载了
https://www.oracle.com/java/technologies/downloads/ |
 |
53
laojin 72 天前
JDK 21 is the latest long-term support release of Java SE Platform.
|
 |
54
QWE321ASD 72 天前
一直有人说不好升级,排除中间件依赖的包改名或者移除的问题,模块化也没那么麻烦啊,更何况有类路径模式,即不创建 module-info 的用法,这种用法和用 jdk8 用着几乎没有区别
|
 |
55
voidmnwzp 72 天前 via iPhone
1.国内不会用 jdk8 以外的版本
2.同步原语没用协程重写，所以然并卵 |
 |
56
fox0001 72 天前 via Android
终于来了，但是要等各方面的跟进…
|
 |
58
nnegier 71 天前 via Android
java21 可以跑 java8 的字节码吗？
|
|
59
mmdsun 71 天前 via iPhone
|
|
60
Subfire 71 天前
终于 GA 了, https://jdk.java.net/21/
|
|
61
Aresxue 71 天前
@mmdsun 真这么简单早升级完了，光 JPMS 和反射的限制就够喝一壶的，更别提原有的 java agent 可能都要失效了，我手上的项目 100 多个应用，2000 多个 pod ，要真到 21 没个两年下不来。
|
|
62
zhouhu 71 天前
@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. |
|
64
zhouhu 71 天前 1
@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. |
|
65
Subfire 71 天前
为啥换成 JDK21 后,
import java.util.concurrent.TimeUnit; 这个都报错 |
 |
66
javaZhenJuan 70 天前
@Subfire 我的也报错
|
Select Language