[вызов Dispose] пометит его только для сбора. Это правильно?
Нет, это не правильно. Вы неправильно понимаете, что делает «Dispose». Это очень распространенное недоразумение.
Позвольте мне быть предельно ясным в этом вопросе: «Утилизация» сама по себе не имеет абсолютно никакого отношения к сбору мусора. В «Утилизации» нет ничего особенного, чего нельзя было бы сделать ни одним другим методом. с любым другим именем. Многие люди верят в следующие мифы:
- Вызов метода с именем Dispose для объекта, который реализует интерфейс с именем IDisposable, «помечает» объект для сбора.
- Сборщик мусора вызывает IDisposable.Dispose при сборе объекта.
Ни один из этих мифов не является правдой.
Факты:
Вызов «Dispose», когда вы закончите с объектом, является соглашением , предназначенным для того, чтобы неуправляемые ресурсы были очищены перед сборщик мусора приступает к очистке ресурсов управляемой памяти , связанных с объектом.
Сборщик мусора решает, когда объект должен быть собран исключительно на основе того, достижима ли какая-либо ссылка на объект через известный для жизни объект. Вызов «Утилизация» или любого другого метода ничего не делает для недоступности объекта.
Сборщик мусора будет (иногда) вызывать «финализатор» (он же «деструктор») для объекта незадолго до его сбора. В соответствии с соглашением автор объекта обычно выбирает, чтобы финализация объекта была идентична его удалению. Но опять же, это всего лишь соглашение.
Как правило, объект, который только что был удален, должен сообщить сборщику мусора, что сборщик мусора может безопасно пропустить завершение этого объекта, когда он в конечном итоге станет недоступным.
«Утилизация» - это просто метод. Если этот метод сообщает GC кучу вещей, например, «кстати, кто-то уже позаботился о завершении этого объекта», метод может сделать это бесплатно. Нет волшебства, присущего «Распоряжаться». Вы можете написать свой собственный метод «MyDispose» и собственный интерфейс «IMyDisposable», который делал то же самое; GC не знает и не заботится о том, какие соглашения вы выбрали для организации своего кода, чтобы он раньше высвобождал неуправляемые ресурсы.