Какова важность очистки коллекции перед утилизацией

Question

В чем разница между следующими кодами

Код 1:

if(RecordCollections!=null){ 
    RecordCollections.Clear(); 
    RecordCollections=null; 
} 

Код 2:

RecordCollections = null; 

код присутствует внутри a Dispose Метод, есть ли преимущество перед использованием метода Clear перед тем, как сделать коллекцию нулевой? Нужно ли вообще?

Answer 1

Есть ли какие-либо преимущества перед использованием метода Clear перед тем, как сделать коллекцию нулевой.

Невозможно сказать без хорошего Minimal, Complete, and Verifiable code example.

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

Даже вторая имеет очень мало значения и противоречит обычной семантике IDisposable. IDisposable должен быть предназначен только для управления неуправляемыми ресурсами. Он иногда используется для других целей, но это его основная цель. В частности, обычно перед вызовом объекта обычно вызывается Dispose(). Если сам объект будет отброшен, то любые ссылки, которые он хранит для других объектов (например, коллекция), больше не будут доступны, поэтому их установка null не имеет никакого полезного эффекта.

Фактически, в некоторых случаях установка переменной на null может фактически продлить срок службы объекта. Среда выполнения достаточно сложна, чтобы распознать, что переменная больше не используется, и если она содержит последнюю оставшуюся ссылку на объект, объект может стать пригодным для сбора мусора в этой точке, даже если область действия переменной продолжается дальше. Установив переменную в null, сама переменная используется позже в программе, и поэтому среда выполнения не может рассматривать ее как недоступную до этой точки позже, чем в противном случае.

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

Answer 2

Dispose относится к механизму явно зачистить un-managed memory, так что не могут быть очищены с использованием стандартных Garbage Collector, в основном IDisposable будет реализован в классе, которые используют неуправляемый API внутренне как Database Connection.

Стандартная практика:

• также осуществлять Finalizer наряду с, поскольку Dispose является явным вызовом, и если пропущено из-за вызывающий абонентом, то Доработка ли заботиться о чистых мерах, хотя нужно 2 циклов GC.

• Если класс использует любой объект в качестве переменной класса, который реализует сам Dispose, то Dispose должен быть реализован для вызова Dispose в переменной класса.

Что касается кода при условии:

if(RecordCollections!=null){ 
    RecordCollections.Clear(); 
    RecordCollections=null; 
} 

Или

RecordCollections = null; 

Как это связано с очисткой управляемой памяти, она имеет мало пользы, так как GC делает основную работу и Безразлично он мне нужен, но, на мой взгляд, это acceptable practice, где переменные класса явно аннулированы, что делает пользователя разным в каждом распределении и в основном попытка должна быть сделана t o использовать локальные переменные метода до и до тех пор, пока состояние не должно быть общим для вызовов методов. Неправильное использование объекта, может быть намного более контролируемым.

Насколько разница касается, хотя коллекция явно очищается, а затем аннулируются или просто аннулирована, память остается неизменным, до точки GC вызывается, который un-deterministic, но на мой взгляд, это не очень понятно, как GC явно отображает объекты для коллекции, которые не достижимы, но для разных поколений, особенно для более высоких (продвигаемые объекты), если объект явно помечен как null, тогда GC, возможно, придется тратить меньше/не тратить время root/reference, однако нет явной документации, чтобы объяснить этот аспект/реализацию.