1

我想用一个基于文件大小限制或当前日期切换文件的侦听器替换默认的 Microsoft XmlTraceListener。我想保留默认的 XmlTraceListener 文件格式，以便可以使用 ServiceTraceViewer 工具打开文件。

我发现了一篇文章http://www.codeproject.com/Articles/30956/A-Rolling-XmlWriterTraceListener但从评论看来，即使应用了建议的补丁，这个监听器也有一些不稳定性。

然后我找到了微软自己实现的 CircularListener http://msdn.microsoft.com/en-us/library/aa395205.aspx

我想扩展它，但注意到它有 

static CircularStream m_stream = null;

后来这个变量在没有锁的情况下被访问。在阅读http://msdn.microsoft.com/en-us/library/ms733025.aspx时，我发现即使 XmlWriterTraceListener 本身也不是线程安全的。MSDN 说：

因为 System.Diagnostics.XmlWriterTraceListener 不是线程安全的，所以跟踪源在输出跟踪时可能会独占锁定资源。当许多线程将跟踪输出到配置为使用此侦听器的跟踪源时，可能会发生资源争用，从而导致严重的性能问题。要解决此问题，您应该实现一个线程安全的自定义侦听器。

所以本质上，这意味着TraceListener.IsThreadSafe属性与falseXmlWriterTraceListener 一样，所以每次调用 TraceData / TraceEvent 时，更高级别的跟踪系统都会锁定，对吗？

static CircularStream m_stream在它周围添加一个锁并true从覆盖的IsThreadSafe 属性中返回会有什么好处吗？或者它可能与 XmlTraceListener 中已经完成的事情相同？

我该怎么做才能使 CircularTraceListener 线程安全且高效？

4

1 回答 1

1

我认为CircularTraceListener基本上是有缺陷的。正如您所注意到的，有一个static m_stream. 但是，更糟糕的是，当您构造 a 时，CircularTraceListener它会沿着新流传递到基 ( XmlWriterTraceListener)。这意味着虽然CircularTraceListener只知道最后创建的流，但基类可能正在使用许多流之一。而且，当然，如果CircularTraceListener被释放，基类将释放共享m_stream对象。

我建议你不要CircularTraceListener从头开始做任何事情。

更新：

对于像循环日志这样的事情，我在 log4net 和 NLog 方面的运气要好得多。

于 2013-03-15T19:13:29.877 回答