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

欢迎访问我的GitHub

这里分类和汇总了欣宸的全部原创(含配套源码):https://github.com/zq2599/blog_demos
《支持JDK19虚拟线程的web框架》系列文章链接
  • 支持JDK19虚拟线程的web框架 , 之一:体验
  • 支持JDK19虚拟线程的web框架 , 之二:完整开发一个支持虚拟线程的quarkus应用
  • 支持JDK19虚拟线程的web框架 , 之三:观察运行中的虚拟线程
  • 支持JDK19虚拟线程的web框架 , 之四:看源码 , 了解quarkus如何支持虚拟线程
本篇概览
  • 本篇是《支持JDK19虚拟线程的web框架》系列的第五篇 , 也是全系列的终篇 , 之前的文章实战、写代码、读源码 , 想必把大家累坏了 , 今天咱们开启聊天模式 , 畅谈虚拟线程中的一个关键问题 , 在轻松的气氛中学习知识 , 也为整个系列顺利收官
关于ThreadLocal
  • 既然提到了线程 , 自然绕不开ThreadLocal类 , 它提供了线程本地变量 , 此变量和一般的变量不同 。通过get & set 方法 , 每个线程可以获取到自己独立的变量 。这个变量实例通常是私有且静态的 , 可以存储与线程相关的信息 , 如产品id、事务id等 。
  • 下图很形象的展现了ThreadLocal:是完全属于每个线程自己的集合

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

文章插图
虚拟线程中 , ThreadLocal的问题
  • 既然每个线程都可以拥有属于自己的ThreadLocal对象 , 那虚拟线程的情况又如何呢?
  • 虚拟线程的特性 , 使得我们可以在应用代码中创建成千上万个虚拟线程去执行并发任务 , 而无需担心线程数量对整体计算资源的负担 , 如果每个线程都用了ThreadLocal , 那会不会出现成千上万的ThreadLocal对象呢?线程是虚拟的 , 对象可是实实在在的 , 这样会增加系统资源消耗 , 或者影响性能吗?
  • 不过转念一想 , 这么明显的问题 , 连我都能想到 , JDK组织又岂会漏掉?应该是我多虑了吧 , 凭自己"丰富的经验" , 我预测解决方案应该和TLAB(Thread Local Allocation Buffer)类似 , 为海量虚拟线程的ThreadLoacal对象建立映射关系 , 做到高效管理
  • 然而现实很残酷 , 脸 , 被狠狠地抽打 , 通过Oracle官方博客 , 知道实际情况真惨... , 如下图 , 中文注释是我的解读 , 极具悲观色彩 , 如果翻译得不准确请您告知 , 谢谢
【终篇 支持JDK19虚拟线程的web框架,之五:兴风作浪的ThreadLocal】
终篇 支持JDK19虚拟线程的web框架,之五:兴风作浪的ThreadLocal

文章插图
  • 对上述内容 , 个人理解是以下两点:
  1. 虚拟线程中使用ThreadLocal确实会带来内存问题 , 现在还无解 , 连虚拟线程自身的工程Loom都在自己代码中删除ThreadLocal的使用 , 那么我们普通用户敢用吗?还是避而远之吧 , 在虚拟线程中不要用ThreadLocal
  2. 编号429的JEP , 为我们带来了一个解决方案 , 一种名为Scoped values的变量 , 可以在一定范围(scope)内被访问 , 至于这个scope , 可以是一个内存范围(例如临时变量就只能在方法内) , 另外还有一种范围被称为dynamic scope , 这个范围就更加灵活了 , 不过这个JEP当前的状态还很早期 , 如下图 , 还在提案阶段 , 这要是跳票了或者被否了 , 那我博客不就白写了?就此打住吧 , 我不能再研究了

    经验总结扩展阅读