loom 在 quarkus 中的基本应用

[yazinnnn]

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

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

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

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

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

• Blocking 模型无法使用虚拟线程(简称纤程),因为 jdbc 会 pin 住 worker 线程
• Reacitve 模型可以使用纤程,吞吐有所提升,同时保持比较简单的编程模型
• 纤程模型 memory usage 比 reactive 和 blocking 都高
• 纤程跑在 eventloop 线程会导致死锁
• 纤程模型保持了简单模型,高并发(逊于 reactive),但是失去了高效

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

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

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

[TWorldIsNButThis]

kotlin 无栈协程性能稍高于 loom ，其他地方看到的 bench 也是这个结论

[WispZhan]

如果项目里用到了 Reactive ，那么目前还是 Kotlin 胜了。

---

最近把 Spring 项目迁移 Quarkus 的尝试失败了，晚点再看看，先收藏了。

[Jirajine]

纤程是啥，fiber 吗？为啥要用这么奇怪的生造词。

[NXzCH8fP20468ML5]

@Jirajine fiber 的说法来自 ruby ？ ruby 的协程类就叫 Fiber
反正就是协程各种变体呗。

[mind3x]

@Jirajine 就是 fiber ，很早就这么叫了。20 年前 Win32 SDK 里就有 https://docs.microsoft.com/en-us/windows/win32/api/winbase/nf-winbase-createfiber ，当然 Win32 的 fiber 比较原始，需要用户代码自己主动 yield 。

[Jirajine]

@xxfye @mind3x 那就直接叫 fiber 啊，“纤程”这个译名，我还是第一次见。

[yazinnnn]

@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]

只支持阻塞式数据交互的一众数据库们一直在阻碍这些新技术的实用

[mind3x]

@Jirajine 20 年前的书就这么译了

[guyeu]

略看了一下，整理如下，欢迎指正

编译阶段，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]

看到很多文章一致唱好这个虚拟线程。看来生产使用仍有待验证、优化。

[fox0001]

@Jirajine #3
@xxfye #4
@mind3x #5

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

https://openjdk.org/jeps/425