这是一个创建于 762 天前的主题，其中的信息可能已经有所发展或是发生改变。
测试框架是 quarkus(resteasy reactive) 3.3.3
cpu i5 10400
jdk 版本
api 响应内容
测试代码(直接返回字符串与模拟进行 100 毫秒业务后返回字符串)
https://gist.github.com/yazinnnn/92a90ddb81579fdc619ca14395bf3dc2
测试命令(wrk 10 线程 5000 连接 5 秒)
wrk -t 10 -c 5000 -d 5s ~
首尾的 rss 分别为启动时和测试后的内存占用
native 结果(堆内存 200m)
jvm 结果(堆内存 200m)
两者的应用大小及启动时间对比
cpu i5 10400
jdk 版本
api 响应内容
测试代码(直接返回字符串与模拟进行 100 毫秒业务后返回字符串)
https://gist.github.com/yazinnnn/92a90ddb81579fdc619ca14395bf3dc2
测试命令(wrk 10 线程 5000 连接 5 秒)
wrk -t 10 -c 5000 -d 5s ~
首尾的 rss 分别为启动时和测试后的内存占用
native 结果(堆内存 200m)
jvm 结果(堆内存 200m)
两者的应用大小及启动时间对比
 | 1 yazinnnn OP 补充一个 spring webflux 的简单测试(尚未支持 virtual thread) native(-Xmx200m)  jvm(-Xmx200m)  启动时间  |
 | 2 1055619878 2023-09-20 14:33:48 +08:00 有没有省流版本 |
 | 3 taogen 2023-09-20 14:45:06 +08:00 同求 |
 | 4 leexiaolang 2023-09-20 15:48:55 +08:00 内存占用降低，启动时间短，但是性能下降了？ |
 | 5 mmdsun 2023-09-20 16:31:32 +08:00 spring boot 是不是要配置虚拟线程，默认是普通线程池？ |
 | 6 Akitora 2023-09-20 16:41:10 +08:00 看起来在 quarkus 和 webflux 下，测试结束时 native 内存占用是 jvm 的一半左右，但同时吞吐量也下降了是比较意外的，这样的话 native 最大的优势只是启动速度吗…… 以及比较好奇的是 native 会不会在 gc 后把内存还给操作系统？ |
 | 7 zhady009 2023-09-20 18:04:51 +08:00 @Akitora 没有给出 build args ，没指定的话默认是 Serial GC 要加上--gc=g1 看看是不是因为 gc 的原因 |
| 9 zhady009 2023-09-20 18:57:38 +08:00 @ixiaohei https://tschatzl.github.io/2023/08/04/jdk21-g1-parallel-gc-changes.html 还在，反正不是构建 native-image 的话默认都不是这个，无所谓 |
 | 10 netabare 2023-09-20 18:59:21 +08:00 via Android  1 看了一下 quarkus 的 blog ，感觉对这个其实没啥太大的兴趣。reactive 的技术栈下，「开很多个线程」并不是一个痛点。 就是不知道 virtual thread 对 reactive 技术栈有没有什么帮助了。感觉还是存疑。 |
 | 11 salmon5 2023-09-20 19:49:47 +08:00 @ixiaohei JDK21 默认还是 G1GC ，SerialGC 、ParallelGC 都还支持，从 JDK9 废弃 JDK14 移除的是 CMS GC ； JDK21 新增了分代 ZGC ，但不是默认 |
 | 12 ikas 2023-09-20 20:47:27 +08:00 virtual thread 本身就是为了代替 rective ,异步等方式来实现高吞吐 io 的 目前最大的好处也就是是使用简单的同步方式来编写代码,性能肯定还需要打磨的 |
 | 13 Leviathann 2023-09-20 20:50:33 +08:00 @netabare 可以做 await |
 | 14 bringyou 2023-09-20 21:02:54 +08:00 刚好 spring 也出了一篇文章介绍 Java21 + graalvm https://spring.io/blog/2023/09/20/hello-java-21 |
 | 15 cp19890714 2023-09-20 21:03:18 +08:00 1 这个结果很不错了。使用 虚拟线程+同步编程 就可以达到响应式编程 90%的效果，这已经可以降低成本了。 |
 | 16 duduke 2023-09-20 21:26:48 +08:00 cpu 密集型性能肯定会下降，io 密集型的应该会有帮助，看 op 的结果有这个倾向，应该再上点请求量，可能会比较显著 |
 | 17 kneo 2023-09-20 22:38:51 +08:00 via Android 结论？ |
 | 18 ymmud 2023-09-20 22:41:12 +08:00 加上数据库最好 |
 | 19 hez2010 2023-09-20 22:44:59 +08:00 虚拟线程的方式性能是不如 async/await 以及 reactive 的，但好处是解放了双手，不需要大幅度修改代码就能让已有同步阻塞代码的吞吐量得到提升。 |
 | 20 Cabana 2023-09-20 23:04:42 +08:00 感觉还是类似 Kotlin 的协程好用些 |
 | 21 xiaocaiji111 2023-09-21 10:54:42 +08:00 极限性能还是要靠线程池+netty 那一套网络模型，基本上 go 也好，rust 也好，网络库最终都走了这套。不过可以大大降低普通人在业务开发中编写高性能程序的难度，已经很不错了。编译成 native 好像非企业版，默认是 serialGC ，真难顶。 |
 | 22 litchinn 2023-09-21 11:43:11 +08:00 https://www.bilibili.com/video/BV1Ju4y1Q788 这个视频我觉得讲的听清楚的 测试我觉得应该是写个请求，请求其他服务器资源。对比虚拟线程和传统多线程的响应，以及试试虚拟线程的数量级 虚拟线程和原生镜像，使用前需要慎重考虑当前场景是否适用，感觉他们更像是加入的新功能，而非可以完全替代旧有功能的进化版 |
Select Language