loom 在 quarkus 中的基本应用

2022-09-14 20:48:04 +08:00
 yazinnnn

https://www.youtube.com/watch?v=514Ub0jNiII&ab_channel=Quarkusio

前几天 Quarkus Insights 做了一场关于 loom 的应用

有兴趣的朋友可以看一下(我没看完)

看他们展示的 ppt 简单总结一下

https://drive.google.com/file/d/1tcb4uX-UdssdPQeVRIftPl4cfQO8RYs1/view

此刻的感觉是 loom 目前实用度尚不及 kotlin 协程(虽然两者并不在同一条赛道上),毕竟都是 await

但是 kotlin 因为是 cps 变换,所以保持了 reactive 的高性能及高效,也保持了简单模型

不过 kotlin 也有引入新语言及方法染色的问题

2218 次点击
所在节点    Java
12 条回复
TWorldIsNButThis
2022-09-14 22:18:29 +08:00
kotlin 无栈协程性能稍高于 loom ,其他地方看到的 bench 也是这个结论
WispZhan
2022-09-14 23:20:11 +08:00
如果项目里用到了 Reactive ,那么目前还是 Kotlin 胜了。

---

最近把 Spring 项目迁移 Quarkus 的尝试失败了,晚点再看看,先收藏了。
Jirajine
2022-09-14 23:39:23 +08:00
纤程是啥,fiber 吗?为啥要用这么奇怪的生造词。
xxfye
2022-09-14 23:54:17 +08:00
@Jirajine fiber 的说法来自 ruby ? ruby 的协程类就叫 Fiber
反正就是协程各种变体呗。
mind3x
2022-09-14 23:56:11 +08:00
@Jirajine 就是 fiber ,很早就这么叫了。20 年前 Win32 SDK 里就有 https://docs.microsoft.com/en-us/windows/win32/api/winbase/nf-winbase-createfiber ,当然 Win32 的 fiber 比较原始,需要用户代码自己主动 yield 。
Jirajine
2022-09-15 00:01:35 +08:00
@xxfye @mind3x 那就直接叫 fiber 啊,“纤程”这个译名,我还是第一次见。
yazinnnn
2022-09-15 06:08:33 +08:00
@Jirajine jvm 以前有 fiber 实现,貌似是脸书做的
loom 官方也自称纤程
Project Loom: Fibers and Continuations for the Java Virtual Machine

https://cr.openjdk.java.net/~rpressler/loom/Loom-Proposal.html
zhangxzh
2022-09-15 09:09:24 +08:00
只支持阻塞式数据交互的一众数据库们一直在阻碍这些新技术的实用
mind3x
2022-09-15 14:00:11 +08:00
@Jirajine 20 年前的书就这么译了
guyeu
2022-09-15 21:35:50 +08:00
略看了一下,整理如下,欢迎指正

编译阶段,Quarkus 分析代码,识别以下注解:
- @RunOnVirtualThread
- @Blocking
- @NonBlocking

`Virtual Thread`是 Java 的一种数据结构,和操作系统的线程没有对应关系。

对于`@RunOnVirtualThrad`或`@Blocking`或`Reactive`类型的返回值,在执行到这个方法时,这个方法会向`Virtual Thread`注册一个`run()`操作,这个方法会被称为`Poller`的线程调度执行,这个过程中会转存(`park`)线程上下文(堆栈、ThreadLocal ),遇到阻塞逻辑时,`Virtual Thread`会`Pinned`,但不影响实际执行逻辑的线程,方法执行结束(阻塞逻辑完成)时,`Poller`会通过`unpark`操作把逻辑调度回`Carrier Thread`。

对于`@Blocking`或者`Imperative`类型的返回值,这个方法会正常在`Workder`线程执行。


**NEVER BLOCK THE EVENT LOOP**
`Carrier Thread`也是一种`Event Loop`,阻塞`Event Loop`和阻塞`Reactive`模型的`Event Loop`会导致同样的后果(**Crash**)。

### 基准测试

- 响应时间(阻塞模型的响应时间在 1000 并发时超过 5s ,virtual_thread 在 1200 并发时超过 5s ,reactive 模型在 1500 附近超过 5s )
- 低并发(<1000 )时:reactive = virtual_thread > blocking
- 中并发( 1000~1800 )时:reactive > virtual_thread > blocking
- 高并发(>1800 )时:reactive > virtual_thread > blocking
- 吞吐量
- 低并发(<1000 )时:blocking = reactive = virtual_thread
- 中并发( 1000~1800 )时:reactive = virtual_thread >> blocking
- 高兵伐(>1800 )时:reactive ❯ virtual_thread >> blocking

整体上数据远远优于阻塞模型,但略差于 reactive 模型,在响应时间上的差距比较明显。
fox0001
2022-10-03 21:16:13 +08:00
看到很多文章一致唱好这个虚拟线程。看来生产使用仍有待验证、优化。
fox0001
2022-10-03 21:53:06 +08:00
@Jirajine #3
@xxfye #4
@mind3x #5

查了下,貌似官方正式定名为虚拟线程,即 virtual threads 。

https://openjdk.org/jeps/425

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://www.v2ex.com/t/880074

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX