[英]C# ThreadStaticAttribute marked fields are automatically released when thread dies?
I discovered ThreadStaticAttribute
, and I have a lot of questions about it: all my previous thread-dependent static information was implemented as a static dictionary in which TKey is Thread, and when I wanted to access it, I used Thread.CurrentThread and that works.我发现了
ThreadStaticAttribute
,对此我有很多疑问:我之前所有与线程相关的静态信息都被实现为一个静态字典,其中 TKey 是 Thread ,当我想访问它时,我使用了 Thread.CurrentThread 并且有效. But this requires maintenance because if a thread dies, I have to delete the corresponding entry from the dictionary.但这需要维护,因为如果线程死亡,我必须从字典中删除相应的条目。 And I also need to consider thread safety and a lot of other matters.
而且我还需要考虑线程安全和许多其他问题。
By using ThreadStaticAttribute
, all these matters seem to be solved, but I need to be sure of it.通过使用
ThreadStaticAttribute
,所有这些问题似乎都得到了解决,但我需要确定这一点。 My questions are: do I need to delete the instance held by ThreadStaticAttribute
marked fields, somehow, before the thread dies??我的问题是:我是否需要在线程死亡之前以某种方式删除由
ThreadStaticAttribute
标记的字段持有的实例? Where is the information on that field held??该领域的信息在哪里保存? It is in the instance of a
Thread
object, or something like that, so that when it is not used anymore, the garbage collector automatically discards it?它在
Thread
对象的实例中,或者类似的东西,所以当它不再使用时,垃圾收集器会自动丢弃它? Are there performance penalties?有性能惩罚吗? What ones?
有哪些? Is it faster than using a Keyed collection like I was doing?
它比使用像我一样使用键控集合更快吗?
I need clarification on how ThreadStaticAttribute
works.我需要澄清
ThreadStaticAttribute
的工作原理。
No you do not need to delete instances of values help in a field which is tagged with ThreadStatic
.不,您不需要在用
ThreadStatic
标记的字段中删除值帮助的实例。 The garbage collector will automatically pick them up when both the thread and the object are no longer reachable by rooted objects.当线程和对象都不再被根对象访问时,垃圾收集器将自动拾取它们。
The only exception here is if the value implements IDisposable
and you want to actively dispose of it.唯一的例外是如果该值实现了
IDisposable
并且您想要主动处置它。 In general this is a hard problem to solve for a number of reasons.一般来说,这是一个很难解决的问题,原因有很多。 It's much simpler to not have values which implement
IDisposable
and are in a ThreadStatic
field.没有实现
IDisposable
并且位于ThreadStatic
字段中的值要简单得多。
As to where this field is actually stored, it's somewhat irrelevant.至于这个字段实际存储在哪里,这有点无关紧要。 All you need to be concerned about is that it will behave like any other object in .Net.
您需要担心的是它的行为与 .Net 中的任何其他对象一样。 The only two behavior differences are
唯一的两个行为差异是
Marking a static member variable as [ThreadStatic] tells the compiler to allocate it in the thread's memory area (eg. where the thread's stack is allocated) rather than in the global memory area.将静态成员变量标记为 [ThreadStatic] 会告诉编译器将其分配到线程的内存区域(例如,分配线程堆栈的位置)而不是全局内存区域。 Thus, each thread will have its own copy (which are guaranteed to be initialized to the default value for that type, eg. null, 0, false, etc; do not use in-line initializers as they will only initialize it for one thread).
因此,每个线程都有自己的副本(保证初始化为该类型的默认值,例如 null、0、false 等;不要使用内联初始化程序,因为它们只会为一个线程初始化它)。
So, when the thread goes away, so does its memory area, releasing the reference.因此,当线程消失时,它的内存区域也会消失,释放引用。 Of course if it's something that needs more immediate disposal (open file streams, etc) instead of waiting for background garbage collection, you might want to make sure you do that before the thread exits.
当然,如果它需要更直接的处理(打开文件流等)而不是等待后台垃圾收集,您可能希望确保在线程退出之前执行此操作。
There could be a limit to the amount of [ThreadStatic] space available, but it should be sufficient for sane uses.可用的 [ThreadStatic] 空间量可能存在限制,但对于正常使用来说应该足够了。 It should be somewhat faster than accessing a keyed collection (and more easily thread-safe), and I think it's comparable to accessing a normal static variable.
它应该比访问一个键控集合要快一些(并且更容易线程安全),我认为它与访问一个普通的静态变量相当。
Correction: I have since heard that accessing ThreadStatic variables is somewhat slower than accessing normal static variables.更正:我听说访问 ThreadStatic 变量比访问普通静态变量要慢一些。 I'm not sure if it is even actually faster than accessing a keyed collection, but it does avoid issues of orphans (which was your question) and needing locking for threadsafety which would complicate a keyed-collection approach.
我不确定它是否真的比访问键控集合更快,但它确实避免了孤儿问题(这是你的问题)并且需要锁定线程安全,这会使键控集合方法复杂化。
声明:本站的技术帖子网页,遵循CC BY-SA 4.0协议,如果您需要转载,请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.