写入 log4net FileAppender 时存在多线程性能问题

TickZoom 是一款非常高性能的应用程序，它使用自己的并行化库和多个操作系统线程来平滑地利用多核计算机。

该应用程序遇到了瓶颈，用户需要从单独的操作系统线程将信息写入 LogAppender。

FileAppender 使用 MinimalLock 功能，以便每个线程都可以锁定并写入文件，然后释放它以供下一个线程写入。

如果 MinimalLock 被禁用，log4net 会报告有关文件已被另一个进程（线程）锁定的错误。

log4net 执行此操作的更好方法是使用单个线程负责写入 FileAppender，而任何其他线程只需将其消息添加到队列中即可。

这样，可以禁用MinimalLock来极大地提高日志记录的性能。

此外，应用程序会执行大量 CPU 密集型工作，因此使用单独的线程写入文件也将提高性能，这样 CPU 就不会等待 I/O 完成。

那么问题来了，log4net 已经提供这个功能了吗？如果是这样，如何启用线程写入文件？也许还有另一个更高级的附加程序？

如果没有，那么由于 log4net 已经封装在平台中，因此可以在 TickZoom 代码中为此目的实现单独的线程和队列。

真挚地， 韦恩

EDIT:

谢谢，答案似乎指向开发我们自己的解决方案，也许以某种方式作为 log4net 的扩展。他们清楚地表明 log4net 不会做这种类型的事情。

此外，我们刚刚意识到我们可能正在“滥用”日志系统，该系统主要用于人类可读的消息，以通知重要事件或调试信息。软件输出的这个特定部分仅真正用于验证系统准确性的自动化工具。

当然，我们也以“正常”方式使用 log4net 进行调试、警告等。

但这些更像是“事务日志”，而不是调试或用户通知日志。更具体地说，这些日志不需要人类直接可读。如果需要，某种“查看器”可以以 ASCII 形式显示内容。

因此，我们计划将这些事务类型日志写入高速二进制存储。

谢谢，看来下面的两个答案都对开发我们自己的解决方案有很大的推动作用。

Log4net 不支持您描述的确切场景。不过，它确实提供了其他不锁定的附加程序，例如数据库附加程序或 UDP 附加程序。这里有一些想法：

1. 将您的消息记录到消息中 队列，然后有一个读者（或 几个读者）读完消息 队列并将它们写入日志。 这提供了一个可靠的机制 发送/写入消息。说实话 不知道是否已经有 MSMQ 附加程序，但编写它 自己也不会太辛苦。

2. 使用UDP附加器发送 消息，然后编写自己的消息 监听这些的服务 消息并将其写入文件。

我认为您可以在这里检测到一个主题...基本上使用非阻塞附加程序之一（或编写您自己的）并实现您自己的服务，该服务从附加程序接收消息并将它们写入文件。