c# - ThreadStatic、ThreadLocal、GetData 比为线程创建对象实例有什么优势？

Question

有 friend 问我ThreadStatic和ThreadLocal哪个更好。检查我告诉他的文档 ThreadLocal 看起来更方便，自 .NET 4.0 以来可用，但我不明白为什么要使用它们中的任何一个而不是为线程创建对象实例。它们的目的是存储“线程本地数据”，因此您可以不那么笨拙地调用方法并避免在某些情况下锁定。当我想要这样的线程本地数据时，我总是在创建类似这样的东西:

    class ThreadHandler    {        SomeClass A;        public ThreadHandler(SomeClass A)        {            this.A = A;        }        public void Worker()        {        }    }

如果我只想触发并忘记线程，它将是 new Thread(new ThreadHandler(new SomeClass()).TheWorkerMethod).Start()，如果我想跟踪线程，它可以添加到集合中，如果我想跟踪数据 ThreadHandler 可以添加到集合中，如果我想同时处理这两者，我可以为 ThreadHandler 创建 Thread 属性并将 ThreadHandler 放入集合中，我想要线程池，它是 QueueUserWorkItem 而不是 new Thread()。如果范围简单，它就简短而简单，但如果范围变大，它就很容易扩展。

当我试图用谷歌搜索为什么在对象实例上使用 ThreadLocal 时，我所有的搜索最终都解释了 ThreadLocal 如何比 ThreadStatic 大得多，在我看来这就像人们解释他们有这个笨拙的 Screwdriver ，但现在是工具箱有很重的事件 Spanner ，敲钉子更方便。虽然工具箱一开始有一把锤子。

我知道我遗漏了一些东西，因为如果 ThreadStatic/ThreadLocal 没有优势，它们就不会存在。有人可以指出 ThreadLocal 相对于为线程创建对象实例的至少一个显着优势吗？

UPD:看起来像 this 的两倍，我想当我在谷歌上搜索“java”关键字时让我失望了。因此至少有一个优势 - ThreadLocal 更自然地与任务并行库一起使用。

Answer 1

I don't get advantage of ThreadLocal over creating an instance of object for a thread.

你是对的，当你可以控制正在创建的线程以及它们的使用方式时，将整个线程包装在一个帮助类中并让它从那里获取“线程本地”数据会非常方便.

问题在于，尤其是在大型机构项目中，您并不总是拥有这种控制权。您可以启动一个线程，并调用一些代码，并且该线程可能会通过调用分散在 3 个内部团队和一个外部承包商团队拥有的 10 个项目之间的数百万行代码来实现。祝你在任何地方都能找到其中的一些参数。

线程本地存储让这些人无需显式引用表示该线程上下文的对象即可进行交互。

我遇到的一个相关问题是将数据关联到某个线程和由该线程创建的每个子线程(因为我的大型项目创建它们自己的线程，所以线程本地不再工作) ，看到我有这个问题:Is there any programmable data that is automatically inherited by children Thread objects?

归根结底，这通常是惰性编程，但有时您会发现恰好需要它的情况。