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

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

以前我也经常遇到这个问题，直到换了 64G 的 studio

疫情啥情况哇

maven 项目启动主类的时候默认没有把 provided 的依赖放在 classpath ，IDEA 有个启动选项可以很方便调整这个行为，vscode 不行...

c++必了解啊，后面可以转全栈

填了几十遍验证码，放弃了

想问下楼上鼓吹 restful 风格的大佬，业务内部的错误码咋给客户端？ 401 Bad Request + {"err": 1001, "msg": "are you ok?"}

Redis 开 AOF 就不会丢数据，但其实实际上手游那点数据量随便哪个 SQL/NoSQL 都没啥压力。

locla 是个 typo 吧，如果这都能跑的话确实有点惊讶

三代是 typec 口吗

找他聊聊吧，听你这意思是一个技术出身的老板，这方面通常是比较好沟通的。