Сборка мусора с помощью IDisposable

Давайте проясним это. Предположим, что рассматриваемый ресурс является дескриптором файла. Сборщик мусора ничего не знает ни об дескрипторе файла, ни о том, как его освободить. Дескриптор файла — это просто целое число.

Если StreamWriter, который удерживает дескриптор файла, получает сборку мусора, сборщик мусора помещает объект в очередь завершения. Когда очередь финализации запускается, она вызывает финализатор объекта, и это освобождает дескриптор файла.

Это все ясно? Сборщик мусора не освобождает ресурс; единственный ресурс, о котором знает сборщик мусора, — это объекты в памяти. Прежде чем объект будет освобожден, он финализируется, поэтому сам объект знает, как освободить ресурс.

using(x) — это детерминированный шаблон. Это гарантирует, что Dispose() вызывается в реализаторе при прохождении определенной точки в потоке выполнения. Сборщик мусора, с другой стороны, не является детерминированным, потому что вы точно не знаете, когда объект будет фактически удален. using гарантирует, что объект выполнит свой код очистки (что бы это ни было) тогда, когда вы этого ожидаете, а не когда-то в будущем.

Если больше нет ссылки на этот StreamWriter, он в конечном итоге будет удален сборщиком мусора, но это зависит от сборщика мусора, когда это происходит - это не детерминировано, поэтому вы всегда должны использовать блоки using, когда можете.

Вы должны всегда вызывать Dispose(), когда закончите использовать объект IDisposable. Заявление using — отличный инструмент для того, чтобы убедиться, что вы соблюдаете это правило.

Цель IDisposable — разрешить классам удалять выделенные неуправляемые ресурсы, которые не будут автоматически очищаться при сборке мусора.

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

Вот почему существует оператор using; он обеспечивает удобный синтаксис для использования объектов IDisposable и определяет четкую область применения этих объектов.

Также обратите внимание, что сборщик мусора никогда не вызывает сам Dispose(), но также обратите внимание, что рекомендуется следовать Завершить/удалить шаблон, как описано в MSDN. Если объект соответствует шаблону Finalize/Dispose, Dispose() будет вызываться, когда сборщик мусора вызывает финализатор.

Я разговаривал с человеком об использовании инструкции(). Он сказал, что если мы НЕ будем использовать оператор using() для чего-то вроде StreamWriter, если произойдет какое-либо исключение, ресурс НИКОГДА не будет собран.

Оператор using не имеет ничего общего со сборкой мусора. Как только объект не имеет активных ссылок, он становится пригодным для сборки мусора.

Я понимаю, что нужно использовать оператор using(), но я не согласен с тем, что ресурс никогда не будет собран.

О, тогда ты прав.

Я думаю, что оператор using() вызовет метод dispose() в конце, что может значительно ускорить сбор.

Это может или не может сделать сбор быстрее. Обычно метод dispose вызывает GC.SupressFinalize(object), что означает, что финализатор не будет вызываться при сборке мусора. Вместо этого объект будет просто собран. Так что это может сделать сбор быстрее.

Если вы хотите сказать, что это заставляет объект собираться немедленно, а не позже, то это будет неверно. Подходящие объекты собираются всякий раз, когда к ним обращается сборщик мусора, никогда раньше, и объект становится подходящим, как только у него нет активных ссылок, на что оператор using мало влияет. На самом деле, поскольку блок finally в операторе using содержит живую ссылку, я могу представить сценарии, в которых он мог бы увеличить время жизни объекта, но этот эффект не рассматривается, поскольку управление временем жизни объекта это не точка использования. Детерминированная утилизация неуправляемых ресурсов — это смысл оператора using.

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

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

использование по существу такое же, как следующее (проверьте IL обоих, если вы сомневаетесь в этом):

 try
 { 
      IDisposable o = new Object();
 }
 finally
 {
      o.Dispose();
 }

Пока рассматриваемый объект реализует IDisposable, будет вызываться метод Dispose(), а ресурс, ожидающий чего-то глупого, закодированного в Dispose(), будет собирать мусор. Когда? Не вопрос, на который я могу ответить.

Возможно ли, что элемент никогда не будет GCed. Ну, никогда — это долго, но теоретически возможно, если выйдет за рамки первого поколения и просто останется там. Проблема? Нет, если память со временем понадобится, она будет очищена. Часто неправильно воспринимается как утечка памяти? Несомненно.

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

Оглядываясь назад, StreamWriter, вероятно, должен был иметь реализацию IDisposable, которая ничего не делает, но иметь класс-потомок StreamOwningWriter, реализация которого будет удалять переданный поток. В качестве альтернативы он мог бы иметь параметр конструктора и свойство, чтобы указать, следует ли удалять поток при вызове его собственного метода Dispose. Если бы был выбран любой из этих подходов, правильным поведением всегда был бы вызов Dispose для StreamWriter (и пусть «StreamWriter» (который может быть либо StreamWriter, либо StreamOwningWriter) беспокоится о том, действительно ли Dispose должен что-то делать) .