命名线程很有用，这样人们就可以弄清楚哪些线程在做什么，以进行诊断和调试。

在高度多线程的应用程序中，是否有一种比另一个应用程序更好的特定命名约定？有指导原则吗？线程名称应包含哪些信息？我们对命名线程有什么了解，这可能会对其他人有所帮助？

解决方案

嗯...在我编写的大量多线程应用程序中，通常会有多个线程执行相同的功能，因此我不确定在这种情况下命名线程是否很有用。就是说，我确实为每个线程分配了一个整数ID，该ID会打印在该线程生成的日志消息中，以帮助调试。

是的，对于其他具有专门职责的线程的应用程序，是的，我用描述性的方式命名它们...但是我之所以没有这样做，是因为它是线程化的应用程序，而我这样做是因为这是编码的最佳实践。

我倾向于使用与命名方法或者变量相同的命名线程。选择一些简明扼要的描述线程负责的过程的内容。我不认为我们可以或者应该在线程名称中添加很多其他信息。表达力强但简洁是主要目标。

唯一的约定可能是向作为池一部分的线程添加一个递增的后缀。

据我所知，没有标准。随着时间的流逝，我发现这些准则会有所帮助：

• 使用短名称，因为它们不会使日志文件中的行太长。
• 在重要部分的开头创建名称。图形用户界面中的日志查看器通常具有带列的表，并且线程列通常很小，或者我们阅读其他内容后会变小。
• 请勿在线程名称中使用单词" thread"，因为它很明显。
• 使线程名称易于grep-able。避免使用类似的听起来线程名称
• 如果我们有多个具有相同性质的线程，请使用适合日志记录习惯的一个应用程序或者一个日志文件唯一的ID枚举它们。
• 避免使用诸如" WorkerThread"(如何命名接下来的5个工作线程？)，" GUIThread"(哪个GUI？用于一个窗口？用于所有内容？)或者"计算"(用于计算什么)之类的概括。
• 如果我们有一个使用线程名来grep应用程序的日志文件的测试组，请不要在一段时间后重命名线程。测试人员会讨厌我们这样做。经过良好测试的应用程序中的线程名称应该保留下来。
• 如果我们有为网络连接提供服务的线程，请尝试在线程名称中包含目标网络地址(例如channel_123.212.123.3)。如果同一主机有多个连接，请不要忘记枚举。

如果我们有很多线程而忘记命名，那么日志机制应改为输出唯一的线程ID(特定于API，例如通过调用pthread_self())

命名线程很有用，我们应该遵循一个命名约定，该约定应适用于变量，方法或者类。根据他们的工作来命名并简洁。如果我们遇到需要线程转储的问题，那么最好检查一下名称并知道在代码中查找该问题的位置，而不是检查堆栈跟踪和猜测。

唯一的不同是，如果有多个相同类型的线程，则我们确实应该添加某种索引，因为线程名称应该唯一，以满足某些API。如果我们显示线程名称以了解应用程序在不同线程上执行部分执行时的行为，也可以帮助记录日志。

尽管Thorsten的答案是最全面的，但我们可能需要看看Tomcat如何命名其线程。我发现这很有用。我们正在使用石英调度程序运行多个线程，Thorsten建议使用许多命名规则。

我们要使用线程池吗？如果是，那么这将减少我们添加更多有用的元信息的机会。如果没有，那么天空就是我们可以拥有多少有用信息的限制。

关于什么：

[名称空间]。[类] [。类...]。[方法] [当前线程]？

因此，我们有以下名称：

Biz.Caching.ExpireDeadItems1
Biz.Caching.ExpireDeadItems2
Biz.Caching.ExpireDeadItems3

等等，针对每个线程。

我已经看到了.NET中线程的几种命名约定。

有些人更喜欢在名称的开头(例如tMain Thread)使用" t"，但我认为它没有任何实际价值。
而是为什么不只使用简单的描述性名称(行变量)，例如HouseKeeping，Scheduler等。