使用 ThreadPool 进行应用程序范围的日志记录？
作为这个问题的后续讨论讨论ThreadPool的使用与专用线程：
何时使用专用线程（优先级较低）进行应用程序范围的日志记录以及何时使用线程池？
As a followup on this question discussing the use of the ThreadPool vs a dedicated thread:
When would you use a dedicated thread (with lowered priority) for applicationwide logging and when would you use the ThreadPool?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我要做的完全取决于我的应用程序及其日志记录组件的要求。
如果日志记录是关键任务（例如，您可能需要能够根据日志重播最近的流量），那么专用线程更有可能是正确的方法。
如果日志记录是“尽力而为”，那么 ThreadPool 就可以满足应用程序所需性能和延迟的其他限制。记录器的异步 I/O 在这里就可以了。由于您建议假定的记录器线程的优先级较低，因此这可能与您的应用程序的配置文件匹配。
如果线程池上正在发生更重要的工作，那么我不会超载它来进行日志记录，尤其是。如果日志记录本身很重要 - 您很可能会执行同步、刷新 I/O 来写出日志，这可能是一个瓶颈，具体取决于您希望记录的内容量。
What I would do is completely dependent on the requirements of my app and its logging component.
If logging is mission-critical (maybe you need the ability to replay recent traffic based on the log, for example) then a dedicated thread is more likely the right approach.
If logging is 'best effort', then ThreadPool would be fine subject to other constraints on your app's required performance and latency. Async I/O for the logger would be fine here. Since you suggest lower priority for your putative logger thread, this may match your app's profile.
If more critical work is happening on the ThreadPool then I would not overload it to do logging, esp. if logging itself is important - you could well be doing synchronous, flushed I/O to write out the logs and that's a possible bottleneck depending on the volume of stuff that you wish to log.
如果日志记录并不重要并且您想异步执行，那么我建议使用单个后台线程进行日志记录并使用生产者/消费者队列来发送日志消息。与线程池相比，这可以提高性能，因为单个线程在不太关键的日志上执行 I/O，而阻塞其他线程上的较高优先级 I/O 的可能性较小。
您还可以使用此机制来确保在记录之前提交关键日志。将它们添加到队列中，然后有一种机制来等待特定消息被提交。
If logging is not critical and you want to do it asynchronously then I would recommend using a single background thread for logging and a producer/consumer queue to send log messages. This can achieve improved performance over threadpool since you have a single thread performing I/O on less-critical logs which would have less of a likelyhood to block higher-priority I/O on other threads.
You can also use this mechanism to make sure critical logs are committed before logging. Add them to the queue and then have a mechanism to wait until that particular message is committed.