为什么在 .NET 中命名线程？
我一直习惯这样命名我的线程，因为我有时会读到这样做，但我突然想到我从未使用过任何显示线程名称的调试工具。
命名线程什么时候有用？我什么时候才能真正看到线程的名称？我应该为某些分析工具命名线程吗？什么工具？
I've always been in the habit of naming my threads like this because I read sometime to do so, but it occurred to me that I've never used any debugging tool that showed a thread's name.
When would naming a thread be useful? When would I actually see the name of a thread? Should I name threads for some profiling tools? What tools?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
至少，当您可以快速识别需要调查（或切换到或挂起）的线程状态时，它会使调试更快一些。另请参阅 中的几个答案这个问题。
Visual Studio 至少从 VS2003 开始就有线程窗口。该 MSDN 页面还提供了线程窗口的一些用途。
At the very least, it makes debugging a little quicker when you can quickly identify which thread's state you need to investigate (or switch to or suspend). See also a couple of the answers in this SO question.
Visual Studio has had a threads window at least since VS2003. That MSDN page also features a couple uses of the threads window.
和你一样，我在调试时很少使用线程名称。我知道“线程”窗口就在那里，并且我时不时地使用它。当我使用它时，我很高兴我已经命名了我的线程。
也就是说，在将消息记录到事件查看器、日志文件、控制台等时，我使用线程的名称 (System.Threading.Thread.CurrentThread.Name)。特别是在出现错误的情况下，它为我提供了额外的洞察力到底发生了什么。我使用堆栈跟踪来查明代码中错误的位置，并使用线程名称为堆栈跟踪提供一些上下文。
Like you, I seldom have use for thread names when debugging. I know the Threads window is there, and I've used it every now and then. And when I have used it, I'm glad that I've named my threads.
That said, I use the name of a thread (System.Threading.Thread.CurrentThread.Name) when logging messages to the Event Viewer, log files, the console, etc. Especially in the case of errors, it provides me that extra insight into what exactly was going on. I use the stack trace to pinpoint the location of the error in the code, and the thread name to give the stack trace some context.