Как уничтожаются объекты и надо ли их самому уничтожать?

Question

[Евгений Иванов]

Вот пример кода.

public static string GetLastFolderName(string filePath)
{
FileInfo fileInfo = new FileInfo(filePath);
return fileInfo.Directory.Name;
}

В коде создается новый экземпляр класса.

В отличии от Delphi, вопрос уничтожения объектов в C# не рассматривается, по крайней мере на начальном и среднем уровне изучения языка. Говорят, что всё делается автоматически.
(в Delphi мы это делаем сами, "руками" и часто если забыл удалить объект, это приводит к ошибкам)

Как виртуальная машина .NET понимает, что объект пора уничтожать? И когда это происходит?
Ведь я могу обратиться к нему в любое время, например запустить приложение на C# и через день обратится к нему из другого сервиса/приложения.

Что будет если нужно выполнить код выше в цикле? То есть будет создано множество объектов.
По идее они мне в дальнейшем не нужны. Как только я получил return (имя папки), этот объект мне не нужен.
И если всё это в цикле, логично будет сразу уничтожить объект.

Как уничтожаются объекты и надо ли их самому уничтожать?

Comments

[Hemul GM]

В шарпе этм занимается сборщик мусора. Вкратце, там есть время жизни и поколения, через которые объект будет считаться не нужным.
Со сборщиком мусора в шарпе не мало проблем. Работает он не так эффективно как ожидаешь.

[Василий Банников]

Hemul GM, зависит от настроек

Можно пример, когда действительно есть проблемы с эффективностью, которые нельзя решить тюнингом или переписыванием кода?

[Роман]

Hemul GM, не совсем точно, поколения введены для оптимизации сборки мусора, а основа это трассировка, в начале запускается фаза маркировки, где помечаются объекты, на которые отсутствуют ссылки, потом фаза чистки и сжатия. А поколения, чтобы это все оптимизировать, сборка может быть запущена в только в 0 поколении, где молодые объекты находятся, может быть во всех, от этого зависит скорость сборки.

[Hemul GM]

Василий Банников, ну так об этом и речь. Что сам он не справляется без подстройки.

Роман, память уже подводит. Я более менее плотно писал на шарпе ещё когда только-только WPF появился.

[Василий Банников]

Hemul GM, можно пример, когда не справляется без подстройки. И пример, когда нечто иное справляется?

Answer 1

[nozd up]

CLRium #5: Garbage Collector. 2019 год
Расширяет понимание работы GC, выделения и использования памяти и т.п. Но без предварительно чтения соответствующего материала, например, у Рихтера, понять будет сложно.

Answer 2

[Василий Банников]

Как виртуальная машина .NET понимает, что объект пора уничтожать? И когда это происходит?

Подробно про сборщик мусора можно почитать тут:
https://habr.com/ru/post/125968/ (не самая актуальная статья, но в целом ок)
https://habr.com/ru/company/clrium/blog/463293/
https://github.com/dotnet/coreclr/blob/master/Docu...

Вкратце, он отслеживает все ссылки на объекты, и если к объекту уже точно никто не сможет обратиться - уничтожает его.
Точный момент времени уничтожения объекта в общем случае сложно назвать

Что будет если нужно выполнить код выше в цикле? То есть будет создано множество объектов.
По идее они мне в дальнейшем не нужны. Как только я получил return (имя папки), этот объект мне не нужен.
И если всё это в цикле, логично будет сразу уничтожить объект.

В этом случае GC очень быстро их соберёт, тк единственная ссылка на этот объект была в переменной в этом методе.
Самостоятельно ничего делать не надо.
Никакой утечки памяти не будет.

Правда если этот код будет выполняться уж очень часто, и он является горячим местом - имеет смысл отказаться от FileInfo, и парсить пути без засирания кучи.

Comments

[oleg_ods]

имеет смысл отказаться от FileInfo, и парсить пути без засирания кучи

Чисто для собственного образования, можно пример как распарсить пути без FileInfo. Через статический класс File или есть что то хитрее?

[Василий Банников]

oleg_ods, ручками написать алгоритм для парсинга поверх ReadInlySpan.
Если написать зорошо, то получится вообще без дополнительных аллокаций.
Про метрды в статическом классе не уверен

[oleg_ods]

Василий Банников, Спасибо. Надо будет как-то поиграть с этим.

[Василий Банников]

oleg_ods, по сути Span - это чуть более эффективная альтернатива массивам и строкам

Answer 3

[Александр Ананьев]

https://habr.com/ru/post/125968/

Answer 4

[V Sh.]

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

Comments

[Василий Банников]

И как ты предлагаешь "уничтожать" объекты, если этим заведует GC?
В .NET нельзя вручную освободить память не вызывая GC

[V Sh.]

Василий Банников, ну мы же можем вызвать GC.Collect()? Я не имел ввиду, что мы работаем напрямую с памятью, но у нас есть класс (сборщик мусора) для работы с ней.

[Василий Банников]

V Sh.,
> GC.Collect()
Ещё скажи что будешь в цикле его вызывать :)

Когда вызываешь GC.Collect - он начинает полную процедуру очистки мусора, считает все ссылки, передвигает поколения GC, удаляет, компактирует.
Это очень дорого и только вызовет лишние тормоза. Так что с быстродействием это точно не поможет.
Нельзя его натравить только на один твой конкретный объект.

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

[Роман]

V Sh., вызов GC.Collect без параметров, дает возможность решать сборщику, есть смысл сборку производить или нет. Не факт, что она будет еще.