C# StreamWriter и проблема управления памятью StreamReader, почему память не будет освобождена?

Question

Итак, я использую StreamReader, который использует MemoryStream для записи в StreamWriter и внутри этого приложения, но использование памяти увеличивается на 300 мб (с одного из больших входов) и не освобождается после того, как Im сделал с ним:

До этого и сразу после получения ОЗУ и до 300 Мб меньше, чем после, но я не знаю почему. Я сделал все, что мог придумать, чтобы выпустить эту память, учитывая, что единственное, что происходит здесь, - это то, что данные от читателя помещаются в текстовый файл, я не понимаю, зачем нужно использовать какой-либо большой объем памяти временно. Есть что-то, чего я не хватает? ... Спасибо.

Answer 1

Вы смотрите на ОЗУ, используемую самим процессом? Я бы не ожидал, что это спустится. Процесс будет зависать в этой памяти и повторно использовать его для дальнейших распределений. Он не возвращает его в операционную систему. Именно так работает .NET.

может потенциально получить его, чтобы выбросить память с помощью какого-либо вызова API CLR, но обычно я этого не делал.

Это не означает, что память действительно просочилась - она ​​по-прежнему может использоваться одним и тем же процессом. Например, если вы повторите одно и то же действие, вероятно, не нужно будет увеличивать размер кучи - вы увидите, что использование памяти остается равным на уровне процесса. Используйте графики perfmon CLR, чтобы увидеть память, используемую в управляемой куче, чтобы увидеть, есть ли утечка подлинных.

(Есть также различные другие меры, сколько памяти приложение на самом деле с помощью которого один Интересно, зависит от того, что вы пытаетесь сделать.).

EDIT: Если фрагмент кода действительно свидетельствует о код, который вы используете, тогда есть гораздо более простая альтернатива: поток данных.

using (TextWriter writer = File.CreateText("tempFile.txt")) 
{ 
    CopyText(reader, writer); 
} 

static void CopyText(TextReader reader, TextWriter writer) 
{ 
    char[] buffer = new char[8192]; 
    int charsRead; 
    while ((charsRead = reader.Read(buffer, 0, buffer.Length)) > 0) 
    { 
     writer.Write(buffer, 0, charsRead); 
    } 
} 

Обратите внимание, что если вы не на самом деле изменения кодировки, вы можете сделать это без использования пара TextWriter/TextReader, чтобы начать с.

Таким образом вам не понадобится целая строка в памяти , а также ее двоичное представление (в MemoryStream). Конечно, у вас все равно будет двоичное представление - у вас есть, чтобы написать все в MemoryStream?

Answer 2

Я не уверен, если это поможет, но попробовать using область видимости:

using (StreamReader reader = new StreamReader(somestream)) 
using (StreamWriter log = new StreamWriter("tempFile.txt")) 
{ 
    log.Write(reader.ReadToEnd()); 
} 

Answer 3

В дополнение к тому, что писал Джон, то, как ведет себя среда .NET acutally дает вам некоторые важные преимущества - сохранение памяти, выделенной для процесса, является хорошей вещью, если система не является низкой в ​​памяти (в этом случае среда выполнения, вероятно, выпустит ее).

Например, если вам часто приходится выделять много памяти (как в методе, который вы разместили здесь), то это более эффективно, если процесс уже имеет выделенную память (хотя он не используется для хранения каких-либо .NET). Когда вы запустите его метод в следующий раз, распределение будет намного быстрее!

Во всяком случае, несколько вещей, которые вы могли бы сделать это:

• Вы можете попробовать запустить другую память интенсивного приложение, чтобы увидеть, освобождает ли во время выполнения памяти, когда система нуждается в этом
• Вы можете использовать некоторые .NET профайлер, чтобы увидеть, есть ли какие-либо живые объекты, которые можно было бы ожидать, чтобы быть собраны после запуска метода

Answer 4

в сегменте упомянутых выше, все log, reader и memoryStream все еще находятся в сфере охвата и поэтому не могут собираться мусор. Я не знаю, что имплантирует Dispose на эти объекты, но вполне вероятно, что они все еще хранят большую часть данных в памяти даже после вызова Dispose (поскольку Dispose обычно закрывает только дескрипторы файлов, неуправляемую память и т. и не обязательно удаляет внутренние буферы). Если вы хотите, чтобы это работало так, как ожидалось, вы должны позволить всем ссылочным объектам выйти из области видимости и перестать ссылаться.

Действительно, вам не стоит беспокоиться об этом, если использование памяти не вызывает явной боли.