，这个范围就更加灵活了，不过这个JEP当前的状态还很早期，如下图，还在提案阶段，这要是跳票了或者被否了，那我博客不就白写了？就此打住吧，我不能再研究了
- 搞清楚以上问题后，自己的八卦之心就控制不住了：既然虚拟线程上的ThreadLocal问题这么严重，放眼Java世界的生态这么繁荣，那么多框架和库，那么...你们说
- 有没有哪个倒霉蛋掉进这个坑里去？
- 惨不惨？
- 从坑里爬出来没有？
- 你别说，还真有...
踩坑勇士quarkus
- 这位踩坑勇士，就是贯穿整个《支持JDK19虚拟线程的web框架》系列的quarkus，来吧，一起围观quarkus踩坑，顺便学点知识
- 先看quarkus官方文档《virtual-threads.adoc》，如下图
- 我对上述内容的理解：
- quarkus的人发现：传统线程池模式改用虚拟线程后，性能提升明显，但是反应式框架改用虚拟线程后的提升并不明显，而且还会带来内存消耗过大的问题（看过前面ThreadLocal分析的您，此刻应该猜到原因了了，嘿嘿，您猜的没错）
- 如果您的应用对内存有较严要求，quarkus官方建议您继续坚持(stick)使用反应式框架（这话中透露出浓浓的无可奈何，别催了，搞不定...）
- 接下来官方就要甩锅了，有趣的是，这次接锅的并非JDK，而是大名鼎鼎的...Netty
Netty的问题
- 为什么是Netty接锅呢？
- 首先，Netty使用了Reactor线程模型，而Netty Reactor的核心是Event Loop，下图来自《Netty in Action》,是处理web请求的内部架构图，
- 那么，应该有多少个EventLoop线程呢？下图是Netty源码，默认值是CPU核数的2倍，看得出这是个很保守的数字
