Как контролировать память кортежей?

Question

[Griboks]

Добрый день.
Необходимо возвращать из метода структуру данных. Для это был выбран тип кортежей. В ходе тестирование оказалось, что сборка мусора работает не как ожидалось - создаётся утечка памяти.
Как правильно создавать, удалять и использовать кортежи с минимальными затратами памяти?

(byte[], byte[]) Test() => (new byte[12345678], new byte[16]);
static void Main(string[] args)
{
   var x = Test();
   for(var i=0;i<10;i++)
      x=Test();
}

Каждая итерация увеличивает расход памяти на 150 мб. Где ошибка?

Answer 1

[Griboks]

Кортежы как и другие значимые типы (как и весть стек метода) не очищаются сборщиком мусора до выхода из текущего метода.

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

Answer 2

[DarkByte2015]

А с чего ты взял что тут есть утечка? Да - увеличивает расход памяти, а чего ты ожидал? Ты создаешь на каждой итерации по два массива и сборщик мусора не успевает их утилизировать. По моему это нормально. Лучше подумай как оптимизировать алгоритм чтобы не создавать массивы на каждой итерации. Возможно надо переписать функцию чтобы она принимала ссылки на массивы и заполняла их внутри, а массивы создавались до цикла один раз.

Comments

[Griboks]

А с чего ты взял что тут есть утечка?

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

Да - увеличивает расход памяти, а чего ты ожидал?

Все внешние ссылки на массивы уничтожаются. Следовательно, ожидается освобождение памяти.

сборщик мусора не успевает их утилизировать

А это можно как-нибудь исправить?

это нормально

Если платформа позиционируется как с умной сборкой мусора, это ненормально. Раз сборщик умный, он должен был бы отловить циклические ссылки. Хотя, это же ValueTuple. Я с ними ещё не работал.

оптимизировать алгоритм

Вместо кортежа использовать классы/ref/out. Но хотелось бы использовать современные возможности языка.

[DarkByte2015]

Griboks,

А это можно как-нибудь исправить?

Попробуй GC.Collect

Вместо кортежа использовать классы/ref/out. Но хотелось бы использовать современные возможности языка.

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

[Griboks]

DarkByte2015, GC.Collect не сработало. Придётся использовать старые проверенные способы.
Но всё-таки хотелось бы писать скобки вместо лишнего класса.

[DarkByte2015]

Griboks, не нужен тут никакой класс. Просто два массива передаешь в функцию и заполняешь внутри. Массивы создаются один раз до начала цикла и после каждой итерации очищаются. Либо List, если размер может меняться.

[Griboks]

DarkByte2015, это был лишь пример. В действительности всё намного сложнее.

[Серафим Прозоров]

Griboks, открою Вам секрет: сборщику мусора начхать на кортежи, потому как кортежи -- структуры. Массивы он трогать и не должен, вернее, должен, но когда -- никто не знает, ну нет детерминированного освобождения памяти в дотнете, от слова совсем. Вам предложили переиспользовать массив, идея -- очень даже ничего, также, посмотрите в сторону System.Buffers.
А еще лучше, изучите матчасть, тогда таких вопросов у Вас появляться не будет.

[Griboks]

serafimprozorov, но ведь кортежи содержат массивы. Значит это структуры ссылок. Значит ссылки всё-равно уничтожаются при присваивании. Или не так? И причём тут матчасть? Этот вопрос связан с особенностью платформы.

[Серафим Прозоров]

Матчасть вот при этом)))

А призыв ее выучить основывается на Вашем неполном понимании того, как работает сборщик мусора.

Давайте все же немного копнем в сторону управления памятью. Есть два типа данных -- классы (ссылочные типы, типы-ссылки) и структуры (значимые типы, типы-значения). Между ними есть огромная разница: данные ссылочного типа всегда располагаются строго в управляемой куче, данные же значимого (структуры) там, где, если можно так сказать, используется его экземпляр.

Грубо говоря, когда Вы определили переменную класса, то в стеке потока, в котором исполняется Ваш метод хранится только ссылка (указатель) на область памяти, в которой расположены данные, если Вы объявили переменную значимого типа (структуры), то в стеке потока располагаются сами данные.

Когда структура является полем объекта ссылочного типа, то ее данные опять же расположены прямо в теле объекта (если полем является экземпляр класса, то в теле объекта находится опять же только ссылка).

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

Кроме всего, существуют параметры ref и out (емнип, в последней версии языка есть еще in), так вот, когда параметр помечается ключевым словом ref (равно как и out), передается не он сам, а его адрес, в случае, когда по ссылке передается экземпляр класса, передается, простите за тафтологию, адрес адреса.

Кортежи в C# -- это синтаксический сахар над структурой ValueTuple, в Вашем случае ValueTuple{byte[], byte[]}, он параметризован массивами, которые в свою очередь -- типы ссылочные (классы).

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

Кроме всего прочего, существует понятие поколения объекта и кучи больших объектов. Все новые объекты, занимающие непрерывный участок памяти менее 85000 байт именно так, а не 85КБ, попадают в поколение 0, в нем чаще всего происходит сборка мусора. Все пережившие одну сборку попадают в поколение 1, в котором сборка происходит гораздо (на один или несколько порядков) реже, все, кто переживает сборку мусора в поколении 1 попадают в поколение 2, которое не собирается никогда, ну, вернее, почти никогда, сборка мусора в нем инициируется только в том случае, когда не удается выделить память под большой (85000+ байт) объект.

В кучу больших объектов попадают экземпляры, занимающие непрерывный участок памяти 85000 байт и более (Ваш массив из 12345678 байт как раз такой объект, потому как массив -- непрерывная область памяти), особенность этой области управляемой памяти в том, что сборка мусора в ней во-первых происходит только при сборке второго поколения, а во-вторых в ней не происходит уплотнения, таким образом, возможна ситуация, когда у Вас есть пара гигабайт свободной памяти, а выделить участок для массива из 1024 байт невозможно -- нет свободного участка.

Вы на каждую итерацию выделяете два массива, один из них размером около 12 мегабайт, почему выделяется аж 150 сказать не могу, потому что скорее всего Вы привели не весь код. Памяти у Вас скорее всего вполне достаточно для того, чтобы 10 раз выделить по 150 Мб, то есть сборки мусора не происходит и это нормально. Именно поэтому У Вас просят привести пример боевого кода, тогда будет понятно куда девается память и как все это оптимизировать.

Вообще говоря, если Вы работаете с большими объемами бинарных данных, то я бы посоветовал Вам посмотреть, кроме System.Buffers, в сторону неуправляемой памяти и "сырых" настоящих указателей, не стоит их бояться, при условии, что Вы понимаете, что делаете.

P.S.  Под утечкой памяти и ресурсов вообще, обычно понимается ситуация, когда у Вас не осталось возможности очистить ресурс (например, Вы потеряли указатель на область памяти), то есть то, что описываете Вы, утечкой, строго говоря, не является.

[Griboks]

Серафим Прозоров, спасибо за лекцию, но это не объясняет, почему память очищается, если выделить тело цикла в отдельный метод. И более того, почему память не очищается при GC.Collect();
В любом случае, это уже не проблема.

[Серафим Прозоров]

Не за что, повторюсь еще раз, как и ораторы до меня: без кода никто и ничего не поймет.

Answer 3

[basrach]

В приведенном примере проблемы нет, утечки быть не может. Если утечка 100% есть, то скорее всего, когда создавали этот пример на основе реального кода, вы упустили важную деталь из-за которой и происходит утечка.

Comments

[Griboks]

new byte[16] - это MD5 хеш. Из-за этого могут возникнуть проблемы?

[basrach]

Griboks, нет.
А попробуйте освободить память вот так:

GCSettings.LargeObjectHeapCompactionMode = GCLargeObjectHeapCompactionMode.CompactOnce;
GC.Collect();

[basrach]

Griboks, я сразу не заметил, а видимо проблема в этом: new byte[12345678] - объекты больше 85 кб попадают в так называемый LOH. Этот LOH GC будет освобождать только в крайнем случае. Это не совсем утечка, так как GC знает о таких объектах. Но потребляемая память может расти, да.
https://docs.microsoft.com/en-us/dotnet/standard/g...

[Griboks]

basrach, спасибо за ссылку. Но, тем не менее, даже GC.Collect(); не освобождает память. Но если использовать, например ref, вместо кортежа, память успешно очищается автоматически.

[basrach]

Griboks, ref это способ передачи аргумента, по ссылке в данном случае, иначе по значению. На сборку мусора это никак не может повлиять.

[Griboks]

basrach, удивительно, но ref не засоряет память, а кортеж вместо ней - да. Может я чего-то не понимаю?

[basrach]

Griboks, а покажите код с ref, который работает, и GC.Collect(), который не работает, пожалуйста

[Griboks]

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

Answer 4

[Серафим Прозоров]

Вы выделяете на каждую итерацию новый массив, поэтому, естественно, что после каждой итерации размер используемой памяти вырастает.

Как оптимизировать алгоритм зависит от контекста Вашей задачи: что именно Вы делаете с полученными байтами?

Comments

[Griboks]

Но если заменить кортежи на классы или ref параметры, что в теории требует ещё большего объёма памяти, то память не утекает и держится на уровне одной итерации.

что именно Вы делаете с полученными байтами

Много чего. Например, сериализую хеш.

[Серафим Прозоров]

Вы знаете, я, честно и откровенно говоря, совершенно не понял, что именно Вы заменили на классы и тем более, зачем здесь ref-параметры, по причине отсутствия контекста задачи никаких предположений сделать не могу, тем более что-то посоветовать.
Посему, видимо, присоединюсь к предыдущим ораторам: ошибок нет, а прога работает именно так, как Вы ее написали и делает именно то, что должна: выделяет 100500 байт памяти на каждую итерацию.