4XR拜客生活常识网

• 从上面的架构图和代码可以看出，Netty的反应式框架的核心是使用少量线程来分发web请求，这样的结果仅使用了少量线程资源就能高效处理事件
• 也正式因为有了线程数不多这个前提，在对JSON做序列化处理时，Netty放心的使用了ThreadLocal，毕竟线程少，一个4核的CPU也才8个ThreadLocal，毫无压力
• 而且，为了更加高效，Netty还对ThreadLoacal进行过改造，也就是他们自研的FastThreadLocal
• 然后，时间一天天过去，终于等来了JDK19发布，
• quarkus的反应式web服务模块底层就是Netty，为了用上虚拟线程，他们动手了...咱们脑补一下吧，铺天盖地的虚拟线程线程，铺天盖地的FastThreadLocal对象，炸了吧您...Are U OK ?
• 快乐之后，咱们还是要正视这个问题，表面上看是个坑，实际上是两种设计思路的冲突：

1. 虚拟线程的特性类似golang的协程，很适合直接拿来处理高并发web请求，为每个请求分配一个虚拟线程，逻辑清晰直白，资源消耗又不高，典型的简单高效
2. Netty的反应式模型，核心思路就是用少量线程高效分发大量请求，本身就很高效，而且就算优化，线程数也不是瓶颈
3. 所以，quarkus拎着虚拟线程冲到Netty的地盘一阵操作猛如虎，一看结果...唉，扯远了，来看quarkus官方的解释吧

4XR拜客生活常识网

• 上图红框中那句话很有价值，咱们都能从中领悟到一些东西，我的收获是：当线程数不是系统瓶颈的时候，就别冲动，强行上虚拟线程没用

quarkus强行挽尊

• 既然虚拟线程不适合反应式模型，个人认为：那就不妨大大方方的承认Netty的Reactor是优秀的，放弃将虚拟线程加入进来，这样不是挺好么？
• 然而quarkus接下来的操作还是把我吓到了：既然虚拟线程不适合反应式模型？那就想办法强行让它适合，下图就是quarkus的做法：在构建阶段，找到创建ThreadLocal的那段代码，修改它的字节码，以此来解决前面的内存问题

相关阅读: