使用 ThreadPool 进行应用程序范围的日志记录？答案

【问题标题】：Use ThreadPool for applicationwide logging?使用 ThreadPool 进行应用程序范围的日志记录？
【发布时间】：2010-10-18 23:02:40
【问题描述】：

作为this question 的后续讨论讨论线程池与专用线程的使用：

您何时会使用专用线程（优先级较低）进行应用程序范围的日志记录，何时使用 ThreadPool？

【问题讨论】：

【解决方案1】：

我会做什么完全取决于我的应用程序及其日志记录组件的要求。

如果日志记录是关键任务（例如，您可能需要能够根据日志重放最近的流量），那么专用线程更有可能是正确的方法。

如果日志记录是“尽力而为”，那么 ThreadPool 会很好地受到应用程序所需性能和延迟的其他限制。记录器的异步 I/O 在这里会很好。由于您建议为假定的 logger 线程设置较低的优先级，因此这可能与您应用的配置文件相匹配。

如果 ThreadPool 上发生了更重要的工作，那么我不会重载它来进行日志记录，尤其是。如果日志记录本身很重要 - 您很可能正在执行同步、刷新 I/O 以写出日志，这可能是一个瓶颈，具体取决于您希望记录的内容量。

【讨论】：

如果是“尽力而为”，这个参数对于专用线程怎么样：您可以更改（降低）专用线程的优先级。 AFAIK 你不能（或不应该）用线程池做到这一点。
@bitbonk - 除非你必须这样做，否则我不会去惹这个麻烦。专用线程的一个更好的论点可能是保留顺序。不过，.Net 中内置了生产者/消费者构造来做到这一点。您在使用 .Net 4.0 吗？
还没有，但我可能最终会。
@bitbonk - 你也许可以使用 Microsoft.Practices.EnterpriseLibrary.Logging - 这支持 .Net 3.5 中的异步登录 - 请参阅此处了解场景 - msdn.microsoft.com/en-us/library/ff664736(v=PandP.50).aspx
在添加对 Entlib 的依赖之前，我宁愿为 log4net 添加一个。 :) 但到目前为止，我相信一个小的单一班级服务足以满足我的需求。

【解决方案2】：

如果日志记录不重要并且您希望异步执行，那么我建议使用单个后台线程进行日志记录，并使用生产者/消费者队列发送日志消息。与线程池相比，这可以提高性能，因为您有一个线程在不太重要的日志上执行 I/O，这不太可能阻塞其他线程上的较高优先级 I/O。

您还可以使用此机制确保在记录之前提交关键日志。将它们添加到队列中，然后有一种机制等待特定消息被提交。

【讨论】：