这是一个创建于 280 天前的主题，其中的信息可能已经有所发展或是发生改变。
我说一下我目前的数据：
线程数下降 1200+ 内存下降：5pt CPU 下降：10pt
感觉并没有 N 倍提升，是不是因为我的应用本身就是大部分都是 异步代码的 原因？
 |
1
wbd31 280 天前
pt 是什么单位？
|
 |
3
zhaoziyuan1989 280 天前 via Android
可能是在说 percent?
|
 |
4
ikas 280 天前
虚拟线程最大优势不就是使用传统编程模式实现异步一样的效率么?
|
 |
5
cabing 280 天前
你的版本升级好快了啊。好多项目都是 java8😂java15 都没有
|
 |
6
hepin1989 OP @ikas 我觉得并没有，日常还是写 Flux/Pekko Stream 快一点，而且我在 ConcurrentHashMap 上遇到了 pin Carrier thread 。无解，如果改成全异步的 cache ，反而 CPU 的收益只有 5 个百分点了。
|
 |
7
lmshl 280 天前
https://imgur.com/a/ZyMpzTR
在用了在用了，我现在就写 vt |
 |
8
winterbells 280 天前 via Android  1
第一次见到百分比用 pt 表示…这是缩写还是扩写了%
|
 |
9
kkwa56188 280 天前
If it ain't broke, don't fix it.
如果是生产环境: 非必要不更新, 非必要不升级, 非必要不用新 feature. 跑的好好的东西, 能不动就不动, 一个小版本号都不动. 如果自己折腾, 那随意. |
 |
10
BBCCBB 280 天前
你本来就是异步代码, 提升空间不大.
而且 jdk21 还没 ScopedValue, 不完善. |
|
11
ikas 280 天前
锁的问题需要库,框架适配
毕竟虚拟线程 21 才正式发布,锁与 ThreadLocal 是上生产的最大阻碍 我们基础框架已经升级到了 21,几个项目陆续也升级了,但是虚拟线程只在一个新项目测试版本中开启.. |
 |
12
ByteCat 280 天前
项目都用 Kotlin 写的……换到 Java21 有用吗
|
 |
13
gongxuanzhang 280 天前
我觉得线程池换成虚拟线程性能优化是 0
如果你是 new 出来的线程倒是能优化.. |
 |
16
lidashuang 280 天前
@kkwa56188 总有一天没法维护
|
|
17
hepin1989 OP @lidashuang 改动很小的，不超过 30 行代码老师。
|
 |
18
tramm 280 天前
21 都没升呢
|
 |
19
echo1937 280 天前
@gongxuanzhang 结构化并发实装前，确实少些个意思。即便如此，虚拟线程比线程池灵活，而且即使是线程池，也有 corePoolSize/maximumPoolSize 等问题，该 new 的时候还会 new ，总之还是乐见于多一种方式的。
|
 |
21
dbpe 280 天前 1
Java 的虚拟线程。。。emmm 。。。哎。。。
什么时候可以像 kt 一样。。await 直接用。。 |
 |
22
BeiChuanAlex 280 天前
协程？
现在还在用 jdk 8 的路过~~~~~~~~~~~ |
 |
24
Dragonphy 280 天前
Java 21 虚拟线程的陷阱：我们在 TPC-C for PostgreSQL 中遭遇死锁
https://mp.weixin.qq.com/s/BfDd08j2jQwIOSaxf_mgww |
 |
25
zed1018 280 天前 2
@kkwa56188 请问不升级等到 CVE 高风险漏洞的时候一下升炸十天半个月都 migrate 不完怎么办。怎么老是有这种思想，breaking changes 应该是早发现早治疗，一定要等债务大到爆炸才解决，是想着反正我就干一两年，相信后人的智慧吗？
|
 |
26
cloudyplain 280 天前
个人感觉：虚拟线程最大好处是对编程友好(特别是异步，不借助语法糖实现 await)，性能方面：对异步(netty 、vert.x)甚至可能下降，同步也不见得有多少显著提升(一般是业务代码占大头，helloworld 除外)
|
 |
27
yooomu 280 天前
在一个数据迁移的项目下试用了一下，高度 IO 密集型，使用传统线程池并发根本上不去，CPU 占用过山车。换用虚拟线程，CPU 稳定吃满，迁移效率大幅提升
|
 |
28
Goooooos 280 天前
percent 缩写一般是 pct ，建议别乱缩写，用%谁都看得懂
|
 |
30
ychost 280 天前
虚拟线程对异步本来就没有提升，可能还会下降，对同步代码提升很大
|
 |
31
jjianwen68 280 天前
原本多线程的程序，话说要怎么用虚拟线程，在每个线程耗时处理的地方再开虚拟现场处理，进一步提升效率吗
|
 |
32
liouop 280 天前
目前项目还在 jdk11 kotlin1.9 。。想知道大家的虚拟线程的使用场景都是用来做什么 并发请求数据、数据库 or 计算处理？
|
 |
33
wocanmei 280 天前
感觉内存和 cpu 优化不明显，用处不大吧
|
 |
34
wanguorui123 280 天前
大部分情况下瓶颈在数据库
|
 |
35
yidinghe 280 天前
虚拟线程的好处，一是降低操作系统负担，方便虚拟机自行根据硬件资源调整；二是因为减少了异步代码，可以更方便的使用 ThreadLocal 等工具。总之，它在设计编码方面带来的负担降低是非常显著的。
|
 |
36
zhady009 280 天前 via iPhone
虚拟线程不会让你的代码变快而且还会变慢些，主要还是能提供吞吐量 CPU 利用率，而且代码风格不用变还是同步的写法
|
 |
37
UNCLOSABLE 280 天前
@yooomu 哦？能不能描述以下实现方案啊，感觉很有用啊
|
|
38
yooomu 280 天前
@UNCLOSABLE 就是把原来的使用传统线程池的地方换成调用 Executors.newVirtualThreadPerTaskExecutor()使用虚拟线程执行任务，然后使用 Semaphore 来控制并发量，使用起来和传统线程没多大区别。因为需要从另一个服务器拉数据，一开始没控制并发量，直接把那台服务器干崩了，可见虚拟线程还是挺猛的
|
 |
41
BeautifulSoap 280 天前
公司目前所有项目推荐的版本依旧还只是 17 LTS ，估计还要过段时间才迁移到 21 LTS
|
 |
42
Paracosm 280 天前
如果原先就是做异步处理的话，感觉提升相差无几
|
 |
43
silentsky 280 天前 via Android
至少还是有提升的嘛
|
 |
44
linvaux 280 天前
你发任你发，我用 java8
|
 |
46
wygplay 280 天前
Java 21 虚拟线程适合执行 IO 密集型任务，优势在于提高应用吞吐量
|
 |
47
yef 279 天前
Java8 ，生产非必要不升级，没人主导，没人审批，没法汇报
|
 |
48
wlm201219 279 天前
只有 io 密集型任务，并发量非常大，并且原来的代码会阻塞线程的时候，虚拟线程的效果才会比较明显。但现实中，这种情况已经有了其它的解决方式，就是开发上很麻烦
|
 |
49
siweipancc 278 天前 via iPhone
io 并发的效率高，但是内存吃的哗哗的，最重要的结构化并发还没落地，使用场景有限
|
 |
52
pcdd 220 天前
用了爬虫速度变快了，内存占用也减小不少，代码行数也省了，很香
分代 zgc 开启了吗？使用虚拟线程时，必须使用分代 zgc ，否则 gc 压力比过去大很多 我最开始没开，反而变慢了，开了后就快了 |
Select Language