.NET Framework – 可能的内存泄漏类？

就在前几天，我正在调查内存泄漏，该应用程序在两分钟内将应用程序从大约50MB膨胀到大约130MB。 事实certificate问题出在ConcurrentQueue类。 在内部，类存储数组的链接列表。 当一个项目从ConcurrentQueue出队时，数组中的索引会被碰撞，但该项目仍保留在数组中（即它未设置为null）。 在足够的入队/出队之后，整个arrays节点被丢弃，因此从技术上讲它不是泄漏 ，但如果在ConcurrentQueue中放置大对象，这可能会很快失控。 文档没有记录这种危险。

我想知道基类库中还有其他潜在的内存缺陷吗？ 我知道Substring one（也就是说，如果你调用substring并保持结果，整个字符串仍将在内存中）。 你遇到过的其他人吗？

Answer 1

你是对的。 该bug位于方法System.Collections.Concurrent.ConcurrentQueue+Segment.TryRemove(out T, ref ConcurrentQueue.Segment) 。

如果你在Reflector中查看这个方法，你会看到以下行：

 result = this.m_array[low]; 

它之后应该有以下行：

 this.m_array[low] = default(T); 

作为参考，您可以在方法System.Collections.Generic.Queue.Dequeue()看到如何正确实现它。

Answer 2

虽然不是直接内存泄漏或特定于.net / BCL，但是存在字符串连接（使用+ =运算符）问题。 由于大量的垃圾收集，这在循环中非常占用CPU。

Answer 3

ConcurrentQueue最多只能容纳31个出列的对象。 除非你处理的是非常大的对象图，否则这不应该是一个大问题。

无论如何，如果你没有空间来分配32个对象，那么使用ConcurrentQueue是没有意义的……