ЯЗЫК ПРОГРАММИРОВАНИЯ С# 2005 И ПЛАТФОРМА .NET 2.0. 3-е издание

Троелсен Эндрю

static void Main(string[] args) {

 // Dispose вызывается автоматически при выходе за пределы

 // области видимости using.

 using(MyResourceWrapper rw = new MyResourceWrapper) {

// Использование объекта rw.

 }

}

Если с помощью ildasm.exe взглянуть на CIL-код метода Main, то вы обнаружите, что синтаксис using на самом деле разворачивается в логику try/finally

с ожидаемым вызовом Dispose.

.method private hidebysig static void Main(string [] args) cil managed {

 …

 .try {

…

 } // end try

 finally {

…

IL_0012: callvirt instance void SimpleFinalize.MyResourceWrapper::Dispose

 } // end handler

} // end of method Program::Main

Замечание. При попытке применить using к объекту, не реализующему интерфейс IDisposable, вы получите ошибку компиляции.

Этот синтаксис исключает необходимость применения "ручной укладки" объектов в рамки программной логики try/finally, но, к сожалению, ключевое слово using в C# является двусмысленным (оно используется для указания пространств имен и для вызова метода Dispose). Тем не менее, для типов .NET, предлагающих интерфейс IDisposable, синтаксическая конструкция using гарантирует автоматический вызов метода Dispose при выходе из соответствующего блока.

Исходный код. Проект SimpleDispose размещен в подкаталоге, соответствующем главе 5.

Создание типов, предусматривающих освобождение ресурсов и финализацию

К этому моменту мы с вами обсудили два различных подхода в построении классов, способных освобождать свои внутренние неуправляемые ресурсы. С одной стороны, можно переопределить System.Object.Finalize, тогда вы будете уверены в том, что объект непременно освободит ресурсы при сборке мусора, без какого бы то ни было вмешательства пользователя. С другой стороны, можно реализовать IDisposable, что обеспечит пользователю возможность освободить ресурсы после завершения работы с объектом. Однако, если вызывающая сторона "забудет" вызвать Dispose, неуправляемые ресурсы смогут оставаться в памяти неопределенно долгое время.

Вы можете догадываться, что есть возможность комбинировать оба эти подхода в одном определении класса. Такая комбинации позволит использовать преимущества обеих моделей. Если пользователь объекта не забудет вызвать Dispose, то с помощью вызова GC.SuppressFinalize вы можете информировать сборщик мусора о том. что процесс финализации следует отменить. Еcли пользователь объекта забудет вызвать Dispose, то объект, в конечном счете, подвергнется процедуре финализации при сборке мусора. Так или иначе, внутренние неуправляемые ресурсы объекта будут освобождены. Ниже предлагается очередной вариант MyResourceWrapper, в котором теперь предусмотрены и финализация, и освобождение ресурсов.

// Сложный контейнер ресурсов.

public class MyResourceWrapper: IDisposable {

 // Сборщик мусора вызывает

этот метод в том случае, когда

 // пользователь объекта забывает вызвать Dispose.

 ~MyResourceWrapper {

// Освобождение внутренних неуправляемых ресурсов.

// НЕ следует вызывать Dispose для управляемых объектов.

 }

 // Пользователь объекта вызывает этот метод для того, чтобы

 // как можно быстрее освободить ресурсы.

 public void Dispose {

// Освобождение неуправляемых ресурсов.

// Вызов Dispose для содержащихся объектов,

// предусматривающих освобождение ресурсов.

// Если пользователь вызвал Dispose, то финализация не нужна.

GC.SuppressFinalize(this);

 }

}

Обратите внимание на то, что в метод Dispose здесь добавлен вызов GC.SuppressFinalize, информирующий среду CLR о том, что теперь при сборке мусора не требуется вызывать деструктор, поскольку неуправляемые ресурсы уже освобождены с помощью программной логики Dispose.

Формализованный шаблон освобождения ресурсов

Текущая реализация MyResourceWrapper работает вполне приемлемо, но некоторые недостатки она все же имеет. Во-первых, каждому из методов Finalize и Dispose приходится очищать одни и те же неуправляемые ресурсы. Это, конечно, ведет к дублированию программного кода, что усложняет задачу его поддержки. Лучше всего определить приватную вспомогательную функцию, которая вызывалась бы каждым из двух этих методов.

Далее, следует убедиться в том, что метод Finalize не пытается освободить управляемые объекты, которые должны обрабатываться методом Dispose. Наконец, желательно гарантировать, что пользователь объекта сможет многократно вызывать метод Disposed без появления сообщений об ошибке. В настоящий момент наш метод Dispose таких гарантий не дает.

Для решения указанных проблемы Microsoft определила формализованный шаблон для освобождения ресурсов, устанавливающий баланс между устойчивостью к ошибкам, производительностью и простотой поддержки. Вот окончательная (и аннотированная) версия MyResourceWrapper, для которой используется этот "официальный" шаблон.

public class MyResourceWrapper: IDisposable {

 // Используется для того, чтобы выяснить,

 // вызывался ли метод Dispose.

 private bool disposed = false;

 public void Dispose {

// Вызов нашего вспомогательного метода.

// Значение "true" указывает на то, что

// очистку инициировал пользователь объекта.