终篇 支持JDK19虚拟线程的web框架,之五:兴风作浪的ThreadLocal( 三 )

  • 所以 , quarkus拎着虚拟线程冲到Netty的地盘一阵操作猛如虎 , 一看结果...唉 , 扯远了 , 来看quarkus官方的解释吧

  • 终篇 支持JDK19虚拟线程的web框架,之五:兴风作浪的ThreadLocal

    文章插图
    • 上图红框中那句话很有价值 , 咱们都能从中领悟到一些东西 , 我的收获是:当线程数不是系统瓶颈的时候 , 就别冲动 , 强行上虚拟线程没用
    quarkus强行挽尊
    • 既然虚拟线程不适合反应式模型 , 个人认为:那就不妨大大方方的承认Netty的Reactor是优秀的 , 放弃将虚拟线程加入进来 , 这样不是挺好么?
    • 然而quarkus接下来的操作还是把我吓到了:既然虚拟线程不适合反应式模型?那就想办法强行让它适合 , 下图就是quarkus的做法:在构建阶段 , 找到创建ThreadLocal的那段代码 , 修改它的字节码 , 以此来解决前面的内存问题

    终篇 支持JDK19虚拟线程的web框架,之五:兴风作浪的ThreadLocal

    文章插图
    • 然后我就翻到了上图提到的那段代码

    终篇 支持JDK19虚拟线程的web框架,之五:兴风作浪的ThreadLocal

    文章插图
    • 好奇心驱使 , 我点开上图那个NettyCurrentAdaptor去看了下源码 , 当时就一阵头晕眼花 , ASM风格的代码您能撑多久?试试下图

    终篇 支持JDK19虚拟线程的web框架,之五:兴风作浪的ThreadLocal

    文章插图
    • 按照官方的说法 , 经过他们的优化有百分之八十的提升 , 终于快要达到之前反应式框架的水平了
    • 呃 , 搞得这么辛苦 , 也只是快要追上而已 , 那行 , 咱不用了行吗?
    • 另外 , 上面说的优化手段也不是默认开启的 , 还要做以下几步操作
    1. maven的pom.xml添加以下依赖
    <dependency><groupId>io.quarkus</groupId><artifactId>quarkus-netty-loom-adaptor</artifactId></dependency>
    1. 编译构建的时候 , 增加参数-Dnet.bytebuddy.experimental
    2. 启动的时候 , 增加参数--add-opens java.base/java.lang=ALL-UNNAMED
    • 上述操作算 , quarkus的手段 , 我这个草根只能仰望 , 能开拓自己的见识:原来还可以这样解决问题
    • 但我自己是绝对不敢模仿的 , 开玩笑 , 在编辑阶段注入代码 , 难度太大 , 并且后面如何维护和交接?
    小结
    • 至此 , 咱们压测做了 , 代码写了 , 源码读了 , 八卦也看了 , 《支持JDK19虚拟线程的web框架》系列也到了和您说再见的时候
    • 虚拟线程很诱人 , 欣宸和您一样 , 迫不及待的想在实际项目中将其用上 , 实实在在的解决一些问题 , 正是有了这个目标 , 才促进了《支持JDK19虚拟线程的web框架》系列的诞生 , 本着为我所用的心态去学习、了解、模仿、钻研 , 希望在虚拟线程发布的早期阶段 , 该系列文章能丰富您的知识面 , 为您的决策提供参考信息 , 助您在掌握新技术的时候顺利抢占先机
    • 系列虽然结束了 , 欣宸原创不会停止 , 这里永远是咱们Java爱好者的宁静港湾 , 欢迎您的关注
    欢迎关注博客园:程序员欣宸
    学习路上 , 你不孤单 , 欣宸原创一路相伴...

    经验总结扩展阅读