jdk21的虚拟线程会促进国内公司升级速度吗？还是说万年不变的你发任你发，我用java8？
暂时还不会大规模转21+，估计还要再等2到3年，拭目以待。
21最大的更新就是loom结束了preview正式落地，将一众异步库扫进历史的垃圾桶。
从这个版本开始，做中间件时，netty不再是唯一可选项了。甚至可以说，大多数场景扔掉netty，在保证性能的同时，还能让代码更好维护。
现在oracle helidon提供了许多常用组件，比如http、grpc等，写一些服务已经没啥问题了。
可能很多人还不知道Helidon是什么，给大伙一个直观的认识：Helidon SE可以用来对标Vert.x，Helidon MP可以用来对标Quarkus。
对于老servlet代码，改一个tomcat版本和配置就能无缝切换到loom上，也方便了各大服务升级。
2、3年前go在国内大量增长的时候，有不少业务老大跟风，吭哧吭哧地把java的业务重构成go，有的业务哪怕现在都还没完全重构完，结果现在loom出来了。
不知道当初那些“架构师”、“CTO”会不会被老板骂死。。。（比较一下升级21和用go重写的成本差别~）（不过他们可能也是无奈，毕竟团队可能不重写就没事干了）
loom出来后，再加上native-image，后面也不会再有什么“用go重构java”的需求了，就是可能对打工人不太友好（毕竟升级不会有那么高的人力需求）
（可能很多人知道native-image但不知道tracing agent，这里顺带提一嘴：正常代码 + agent + 放到线上跑2个月 = 自动生成配置文件无缝升级）
目前loom还有一些问题：
有一些历史遗留问题，还需再等各JDBC实现把synchronized删掉改成lock才能发挥最大性能。不过社区考虑的比较多，如果等不及自己统一改一把也不是什么难事。
另外CarrierThreadLocal并没有暴露出来，所以绝大多数的库为了用户友好性，都不会强行add-opens使用它。但是我们可以用一个简单的javaagent做一把hack，把所有有需要的ThreadLocal都改成CarrierThreadLocal（可能还要改一把VirtualThread检查，因为很多库加了个检查然后选择不使用ThreadLocal）。
除开loom，另一个大事件是PanamaAPI基本稳定。在22还有一个API小改动，用反射规避下就能兼容，看起来不会再大改了。
Panama让upcall成为真正可用的特性。之前JNI upcall有点太慢了，而Panama upcall快了几倍，具体数据，几年前网上就有很多人放出来过了，知乎站内就能搜到。
downcall性能其实JNI也挺快的。Panama在downcall上的意义在于，可以省略JNI那样的wrapper，直接加载动态链接库以及根据symbol取函数地址。少一个wrapper可以少一次函数调用。
Panama也给给内存结构做了标准化。现在JVM其实也可以算是支持“结构体”、“union”、“值类型”了。
关于Panama这条线，可以关注下我的Panama Native Interface，是一个代码生成器，工作过程类似于javac -h 。
vproxy-tools/panama-native-interface: Code Generator for Java and C, making it easier to use Java Panama and Graal Native Image (github.com)
目前我已基于此搞了lua、msquic，一部分posix api，一部分dpdk api的Java接入。项目每个功能都有测试用例，而且因为是代码生成器，可以直接从源码层面看到一切细节，可放心使用~
有些答主，比如 @Ivony 说虚拟线程是“语法糖”，说明根本没了解过Java21到底改了什么。也不知道哪来的自信强答各种自己不懂的领域的问题。
