.NET Framework - Возможные классы с утечкой памяти?

Question

Буквально на днях я исследовал утечку памяти, которая вздувала приложение от ~ 50 МБ до ~ 130 МБ менее чем за две минуты. Оказывается, проблема была в классе ConcurrentQueue . Внутри класс хранит связанный список массивов. Когда элемент исключен из ConcurrentQueue, индекс в массиве увеличивается, но элемент остается в массиве (т. Е. Для него не установлено значение NULL). Весь узел массива удаляется после достаточного количества постановок в очередь / удаления, поэтому технически это не утечка , но если поместить большие объекты в ConcurrentQueue, это может быстро выйти из-под контроля. В документации ничего не говорится об этой опасности.

Мне было интересно, какие еще потенциальные ловушки в памяти есть в библиотеке базовых классов? Я знаю о подстроке один (то есть, если вы вызываете подстроку и просто удерживаете результат, вся строка все равно будет в памяти). Кто-нибудь еще встречался?

Answer 1

Вы правы. Ошибка находится в методе System.Collections.Concurrent.ConcurrentQueue<T>+Segment.TryRemove(out T, ref ConcurrentQueue<T>.Segment).

Если вы посмотрите на этот метод в Reflector, вы увидите следующую строку:

result = this.m_array[low];

После него должна быть следующая строка:

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

Для справки, вы можете увидеть, как это правильно реализовано в методе System.Collections.Generic.Queue<T>.Dequeue().

Answer 2

В ConcurrentQueue будет храниться не более 31 объекта из очереди. Это не должно представлять огромной проблемы, если вы не имеете дело с действительно большими графами объектов.

В любом случае, использование ConcurrentQueue не имеет смысла, если у вас нет достаточно места для размещения 32 объектов ...

Answer 3

Хотя это не прямая утечка памяти и не относится только к .net / BCL, существует проблема конкатенации строк (с использованием оператора + =).Это довольно интенсивно использует циклы из-за большого количества мусора.