当线程池线程返回到池中时，更改线程池线程的区域性是否会影响它？
如果我设置线程池线程的 CurrentCulture，当线程完成执行并返回到线程池时会发生什么？它是否会将其 CurrentCulture 重置回默认值（无论这可能意味着什么），还是会保留我在其上设置的区域性？
我希望框架将线程重置为默认状态以防止这种情况，但找不到任何相关文档。我找到的最接近的是来自 ThreadPool：
当线程池复用一个线程时， 它不会清除线程中的数据 本地存储或在字段中 用 ThreadStaticAttribute 标记 属性。因此，数据是 按 1 放置在线程本地存储中 方法可以暴露给任何其他 由相同的方法执行 线程池线程。
这似乎表明线程在返回时未重置。
我尝试了一些示例代码来尝试测试这一点，并且似乎文化已重置，但我不相信我正在正确测试此行为，因为我认为我只使用了一个小的ThreadPool 线程的子集，因此无法确定我正在测试已经具有其区域性集的线程。
If I set the CurrentCulture of a thread pool thread, what happens when the thread finishes execution and gets returned back to the thread pool? Does it get its CurrentCulture reset back to the default (whatever that may mean), or will it retain the culture I have set on it?
I'm hoping that the framework resets the thread to a default state to guard against this, but cannot find any documentation to this effect. The closest I have found is from the MSDN docs for ThreadPool:
When the thread pool reuses a thread,
it does not clear the data in thread
local storage or in fields that are
marked with the ThreadStaticAttribute
attribute. Therefore, data that is
placed in thread local storage by one
method can be exposed to any other
method that is executed by the same
thread pool thread.
This seems to indicate that the thread is not reset when it is returned.
I have tried some sample code to try to test this, and it does seem that the culture is reset, but I am not convinced that I am testing this behaviour correctly as I think I am only using a small subset of the ThreadPool's threads, and so cannot be sure I'm testing a thread that has already had it's culture set.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我不会依赖线程池永远重置信息，特别是因为您引用的文本。
如果您担心“更改”线程池的区域性，我会确保在线程任务完成时重置它。这是一个足够简单的任务。
我不相信当前的线程池会这样做，但即使这样做了，也不能安全地假设 .NET 4+ 的 ThreadPool 实现不会改变。
I would not rely on the ThreadPool ever resetting information, specifically because of the text you quoted.
If you are worried about "changing" the thread pool's culture, I would make sure to reset it when your threaded task is complete. This is a simple enough task.
I do not believe the current threadpool does this, but even if it did, it would not be safe to assume that .NET 4+'s ThreadPool implementation will not change.