特性越多不是更难以升级吗?最好升级的是兼容旧版本且无太多外在 api 才对吧
试想一下,如果虚拟线程需要你强制更新代码实现和调用才能使用那才是大部分人会放弃升级的理由
而目前虚拟线程仅仅只需要替换线程池实现而已,这个升级成本可以简化到一行代码但是可以提升 io 密集型任务性能更好的压榨 cpu 这样升级才是简单低成本吧?

Adghome 有差不多的功能

商家有利可图

没有限制,什么垃圾 app 都能上架辣鸡体制
放开限制,做个 app 还要弄这么多辣鸡体制

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

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

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

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

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

@hhjswf #9 你完全说反了,虚拟线程对 cpu 密集型任务提升很少对 io 密集型任务提升很大

virtual thread 虚拟线程,直接把它当成当成对象去理解就行
创建 100 万个虚拟线程等于创建 100 万个对象罢了,实际上创建的平台线程(不被锁定的情况下)还是 cpu-1 的数量

人活着就是用来吃睡玩的，吃个饭哪那么多潜规则，什么踏🐴的人情世故，我就吃饭，敬 nm 酒，我踏🐴直接跳上桌子 360°托马斯回旋扫完一圈菜，然后扑向领导把领导咬翻，同事也别踏🐴想跑，全啃了，我踏🐴吃吃吃吃吃吃

好消息来了
https://openjdk.org/jeps/439 jdk21 zgc 将使用分代策略并取消多重映射
Generational ZGC from non-generational ZGC, and from other garbage collectors:
No multi-mapped memory
Optimized barriers
Double-buffered remembered sets
Relocations without additional heap memory
Dense heap regions
Large objects
Full garbage collections

串行改并行,同步改异步
十字秘诀送给你

@emSaVya #50 霍金也去过萝莉岛