.NET конструкторы и вопрос управления памятью - PullRequest
1 голос
/ 10 мая 2011

Исходя из более низкоуровневых языков, таких как C ++, и видя, насколько прозрачно управление памятью .NET, у меня есть концерт о фрагменте кода, который я написал.

В C ++ каждый объект обязательно (диктуемые методы проектирования и особенности управления памятью) должен иметь конструктор и деструктор. В .NET деструкторы не нужны так часто, и существуют разные модели того, когда они требуются и как их использовать. У меня вопрос такой. Если у меня есть следующий подобный код (в VB.NET, но в равной степени относится к C #)

Dim myObj As New MyClass( <some parameters here> )

, за которым следует следующая строка в коде

myObj = New MyClass( <some other parameters> )

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

Ответы [ 4 ]

7 голосов
/ 10 мая 2011

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

В отличие от C ++, где вы сами несете полную ответственность за создание и освобождение памяти, в управляемом мире .NET дело обстоит иначе. Все, о чем вам нужно беспокоиться, это создание объекта. Когда на него больше не осталось ссылок на него, он становится пригодным для сбора мусора. Серьезно, я знаю, что это звучит странно, учитывая ваш опыт работы на других языках, но вы действительно должны просто позволить сборщику мусора беспокоиться о таких вещах. «Правильный способ думать о таких ситуациях» - это вовсе не думать о них!

Фактически, только время, которое вам нужно для написания деструктора (и, следовательно, беспокойства об управлении памятью), это если ваш класс использует неуправляемые объекты (такие как дескрипторы окон, объекты GDI + и т. Д.) ) или другие объекты, которые требуют явного закрытия (дескрипторы файлов, соединения с базой данных и т. д.). В мире .NET вы хотите написать деструктор как редко , насколько это возможно, потому что это приводит к небольшому снижению производительности. Специфика заключается в реализации алгоритма сборки мусора, и в какой момент объект может быть собран, но вы не должны пытаться изучить все это.

Важно помнить, что если вам нужно «очистить», когда объект разрушается, вы должны реализовать IDisposable интерфейс , как и многие классы WinForms (например, * 1020). *Control) для внутреннего использования неуправляемых объектов.

Вот несколько полезных ресурсов для получения дополнительной информации о модели сборки мусора в .NET:

2 голосов
/ 10 мая 2011

Объекты в .NET являются сборщиком мусора.Вам не нужно удалять их.

Некоторые объекты, которые содержат неуправляемое состояние (например, что-то выделенное из функции C через P / Invoke), такие как System.IO.Stream, реализуют финализатор и IDisposable.Вы можете использовать их двумя способами:

Stream s = ...
...
s.Dispose();

Или более безопасным способом:

using(Stream s = ...)
{
    ...
} // Dispose is called automatically

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

Любой из ваших собственных классов, в котором есть одноразовые члены, должен также реализовать IDisposable для их очистки.

1 голос
/ 10 мая 2011

Нет это не приведет к утечке памяти. Сборщик мусора вернет предыдущий объект.

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

0 голосов
/ 10 мая 2011

Negative. CLR поддерживает ссылку на все экземпляры со счетчиком ссылок; Время от времени сборщик мусора в памяти запускается и находит все ссылки, на которые не ссылается ни один фрагмент кода, и освобождает эту память.

В вашей ситуации это просто означает, что в какой-то момент в будущем, поскольку вы больше не будете ссылаться на оригинальный экземпляр MyClass, сборщик мусора освободит вам память. Это нормальная операция; так что вам не нужно беспокоиться об этом! = D

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...