我司新立项的项目都是 17 了

都 2202 了，Loom 都进主线了，等等党马上胜利

咋感觉像个 typo 呢。。

看需求感觉不像是个动态规划问题，楼主有解法之后踢我一下，学习一个

@zed1018 Apple Music 已经在排期了

感觉这个特性还真能做到某种层面的高可用，比如我们曾有服务 IP 地址被运营商封掉，如果方式那个服务的域名绑定了两个 IP ，哪怕是同一个主机，也不会导致某省用户全面掉线＋我们花了整整一天排查这个问题

Github

面试是给坑找萝卜，不是给萝卜找伙伴。。

训练打猎的能力

@mitu9527 同意你说的用处不大，但确实不是负优化。最起码可以省去在应用层实现一个连接池的成本哟

服务器内网通信的瓶颈从来不在网络协议上，gRPC 选型使用 HTTP/2 肯定有谷歌自己的倾向在，不过既然是 HTTP 了，选用当时最新的版本好像也没什么毛病。
不知道负优化是咋得出的结论，仅就多路复用一条就很重要呀，想想一个长时间执行的任务需要客户端等待结果，HTTP/1 的话只能新建一个连接，HTTP/2 就可以在同一个连接上用别的 stream 去处理。基于 HTTP/1 虽然也有办法做到这件事，HTTP/2 确实还是有点用的。

oceanhorn

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

编译阶段，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 模型，在响应时间上的差距比较明显。

脸上鼠标就可以操作蓝牙了呀