支持JDK19虚拟线程的web框架，之五（终篇）：兴风作浪的ThreadLocal

关于ThreadLocal

• 既然提到了线程，自然绕不开ThreadLocal类，它提供了线程本地变量，此变量和一般的变量不同。通过get & set 方法，每个线程可以获取到自己独立的变量。这个变量实例通常是私有且静态的，可以存储与线程相关的信息，如产品id、事务id等。

虚拟线程中，ThreadLocal的问题

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

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

• 搞清楚以上问题后，自己的八卦之心就控制不住了：既然虚拟线程上的ThreadLocal问题这么严重，放眼Java世界的生态这么繁荣，那么多框架和库，那么...你们说

1. 有没有哪个倒霉蛋掉进这个坑里去？

2. 惨不惨？

3. 从坑里爬出来没有？

• 你别说，还真有...

踩坑勇士quarkus

• 这位踩坑勇士，就是贯穿整个《支持JDK19虚拟线程的web框架》系列的quarkus，来吧，一起围观quarkus踩坑，顺便学点知识

标签：JDK19,虚拟,框架,threadlocal,提供,资源,方案,繁荣
来源：