2014-10-06 4 views
2

В этой инструкции имеется возможная утечка памяти для очень большой строки (tempText может вырасти до 10 мб).Утечка памяти при небольшой операции

string strXML = new string(tempText.Where(ch => XmlConvert.IsXmlChar(ch)).ToArray()); 

Память, выделенная для strXML не получает выпустили даже после выхода из функции. И я должен вызвать эту функцию несколько раз. Любое возможное решение без этой строки в качестве переменной класса? Я не очень хорошо знаком с управлением памятью C#, может кто-то пролить свет на эту проблему?

+0

Нет ничего особенного в том, как вы создаете 'strXML'. Как вы используете 'strXML' после инициализации? Вы добавляете его в коллекцию? Вы используете его в lambdas, где 'strXML' может быть захвачен? – dasblinkenlight

+0

Использовали ли вы профилировщик памяти, чтобы убедиться, что на самом деле это память, выделенная для 'strXML', которая сохраняется? Является ли еще одна ссылка на строку, которая сохраняется где-нибудь?). –

+0

@ dasblinkenlight позже я использую его с StringReader, который внутри используется() Vlad - наши пользователи запускают наш продукт утром и продолжают работать до конца дня. Это создает проблему, через 4-5 часов. – rplusg

ответ

2

Сборщик мусора не собирает объекты, в которых заканчивается их срок службы. Он выполняет периодически, исходя из своей предполагаемой необходимости, освобождать память. Строка будет в конечном итоге, собранная в некоторый неопределенный момент времени после того, как она длиннее, чем на какой-либо корневой объект.

+0

Я действительно хочу, есть способ, я могу заставить GC очистить объекты, которые мне нужны. – rplusg

+0

@rplusg Зачем вам это нужно? Это почти наверняка будет умнее, чем вы должны определить, когда подходящее время для выполнения коллекции. – Servy

+0

Я понимаю, что GC более умный, но в этом конкретном случае в этой функции я преобразовываю очень большую строку в DataView и привязываю к пользовательскому интерфейсу. Но если пользователь запускает UI 100 раз и закрывается 100 раз. Эта память не освобождается вообще ... даже после ожидания часа. – rplusg

0

Когда вы создаете большой объект, он останется в памяти намного дольше, чем другие мелкие объекты.

Читайте на большом куче и генерации 2-го мусора большого объекта ... он становится техническим, но эти два условия должны быть достаточными, чтобы указать, что здесь происходит.

Вот почему вы не видите, как сборщик мусора восстанавливает эту память так быстро, как хотелось бы.

Чтобы преодолеть это, либо распределите рабочие буферы один раз и повторно используйте их, либо работайте с данными в меньших кусках.

Смежные вопросы