Рассмотрите следующий метод Main(), в котором иллюстрируется использование указанных членов System.GC.
static void Main(string[] args) {
// Вывод оценки (в байтах) для динамической памяти.
Console.WriteLine("Оценка объема памяти (в байтах): {0}", GC.GetTotalMemory(false));
// Отсчет для MaxGeneration начинается с нуля,
// поэтому для удобства добавляем 1.
Console.WriteLine("Число генераций для данной OC: {0}n", (GC.МахGeneration + 1));
Car refToMyCar = new Car("Zippy", 100);
Console.WriteLine(refToMyCar.ToString());
// Вывод информации о генерации для объекта refToMyCar.
Console.WriteLine("Генерация refToMyCar: {0}", GC.SetGeneration(refToMyCar));
Console.ReadLine();
}
Активизация сборки мусора
Итак, сборщик мусора в .NET призван управлять памятью за вас. Однако в очень редких случаях, перечисленных ниже, бывает выгодно программно активизировать начало сборки мусора, используя дня этого GC.Collect().
• Перед входом приложения в блок программного кода, для которого нежелательно, чтобы его выполнение прерывалось возможной сборкой мусора.
• После окончания размещения очень большого числа объектов, когда вы желаете освободить как можно больше памяти.
Если вы сочтете, что будет выгодно выполнить сборку мусора, вы можете явно начать процесс сборки мусора так, как показано ниже.
static void Main(string[] args) {
…
// Активизация сборки мусора и
// ожидание завершения финализации объектов.
GC.Collect();
GC.WaitForPendingFinalizers();
…
}
При непосредственной активизации сборки мусора вы должны вызвать GC.WaitForPendingFinalizers(). В рамках этого подхода вы можете быть уверены, что все лредуcматривающие финализацию объекты обязательно получат возможность выполнить все необходимые завершающие действия, прежде чем ваша программа продолжит свою работу. "За кулисами" GC.WaitForPendingFinalizers() приостановит выполнение вызывающего "потока" на время процесса сборки мусора. Это гарантирует, что ваш программный код не сможет вызвать метод объекта, уничтожаемого в данный момент.
Методу GC.Collect() можно передать числовое значение, указывающее старейшую генерацию, для которой должна быть выполнена сборка мусора. Например, если вы желаете сообщить CLR, что следует рассмотреть только объекты генерации 0, вы должны напечатать следующее.
static void Main(string[] args) {
…
// Рассмотреть только объекты генерации 0.
GC.Collect(0);
GC.WaitForPendingFinalizers();
…
}
Подобно любой сборке мусора, вызов GC.Collect() повысит статус выживших генераций. Предположим, например, что наш метод Main() обновлен так, как показано ниже.
static void Main(string[] args) {
Console.WriteLine ("***** Забавы с System.GC *****n");
// Вывод информации об объеме динамической памяти.
Console.WriteLine("Оценка объёма памяти (в байтах): {0}", GC.GetTotalMemory(false));
// Отсчет для MaxGeneration начинается с нуля.
Console.WriteLine("Число генераций для данной ОС: {0}n", (GC.MaxGeneration + 1));
Car refToMyCar = new Car("Zippy", 100);
Console.WriteLine(refToMyCar.ToString());
// Вывод информации о генерации для объекта refToMyCar.
Console.WriteLine("nГенерация refToMyCar: {0}", GC.GetGeneration(refToMyCar));
// Создание тысяч объектов с целью тестирования.
object[] tonsOfObjects = new object[50000];
for (int i = 0; i ‹ 50000; i++) tonsOfObjects [i] = new object();
// Сборка мусора только для объектов генерации 0.
GC.Collect(0);
GC.WaitForPendingFinalizers();
// Вывод информации о генерации для объекта refToMyCar.
Console.WriteLine("Генерация refToMyCar: {0}", GC.GetGeneration(refToMyCar));
// Проверим, "жив" ли объект tonsOfObjects[9000].
if (tonsOfObjects[9000] != null) {
Console.WriteLine("Генерация tonsOfObjects[9000]: {0}", GC.GetGeneration(tonsOfObjects[9000]));
} else Console.WriteLine("Объекта tonsOfObjects[9000] ужe нет");
// Вывод числа процедур сборки мусора для генераций.
Console.WriteLine("nДля ген. 0 сборка выполнялась {0}: раз(a)", GC.CollectionCount(0));
Console.WriteLine("Для ген. 1 сборка выполнялась {0} раз(а)", GC.CollectionCount(1));
Console.WriteLine("Для ген. 2 сборка выполнялась {0} раз(a)", GC.CollectionCount(2));
Console.ReadLine();
}
Здесь, мы намерений создали очень большой массив объектов с целью тестирования. Как следует из вывода, показанного на рис. 5.6, хотя метод Main() делает всего один явный запрос на сборку мусора, среда CLR выполняет целый ряд операций сборки мусора в фоновом режиме.
Рис. 5.6. Взаимодействие со сборщиком мусора CLR через System.GC
К этому моменту, я надеюсь, вы уяснили себе некоторые детали, касающиеся цикла существования объектов. Остаток этой главы мы посвятим дальнейшему изучению процесса сборки мусора, выяснив, как можно строить объекты, предусматривающие финализацию, и объекты, предусматривающие освобождение ресурсов. Следует заметить, что обсуждающийся ниже подход может быть полезен только при построении управляемых классов с поддержкой внутренних неуправляемых ресурсов.
Исходный код. Проект SimpleGC размещён в подкаталоге, соответствующем главе 5.
Создание объектов, предусматривающих финализацию
В главе 3 говорилось о том, что главный базовый класс .NET, System.Object, определяет виртуальный метод с именем Finalize() (метод деструктора). Реализация этого метода, заданная по умолчанию, не делает ничего.
// System.Object
public class Object {
…
protected virtual void Finalize(){}
}
Переопределяя Finalize() в своем пользовательском классе, вы создаете программную логику "уборки", необходимую для вашего типа. Поскольку этот член определяется, как protected, непосредственно вызвать метод Finalized объекта будет невозможно, Метод Finalize () объекта вызывается сборщиком мусора перед удалением объекта из памяти (если, конечно, этот метод объектом поддерживается).
Ясно, что обращение к Finalize() происходит и в процессе "естественной" сборки мусора, и в случае программной активизации сборки мусора с помощью GC.Collect(). Кроме того, метод деструктора типа будет автоматически вызван тогда, когда выгружается из памяти домен приложения, содержащий выполняемое приложение. Вы, возможно, знаете, что домены приложений используются для размещения выполняемого компоновочного блока и необходимых для него внешних библиотек программного кода. Если вы еще не знакомы с этим понятием .NET, то всю необходимую информацию вам предоставит глава 13. Здесь главное то, что при выгрузке из памяти домена приложения среда CLR автоматически вызывает деструкторы для каждого из предусматривающих финализацию объектов, созданных в процессе выполнения программы.
Теперь, независимо от того, что может говорить вам интуиция разработчика, следует подчеркнуть, что большинству классов в C# не требуется никакой явной "уборки". Причина проста: если ваши типы используют другие управляемые объекты, то все, в конечном счете, будет обработано сборщиком мусора. Создавать класс, который должен заниматься "уборкой", вам придется только тогда, когда этот класс будет использовать неуправляемые ресурсы (например, прямой доступ к дескрипторам файлов ОС, неуправляемым базам данных или другим неуправляемым ресурсам). Вы, наверное, знаете, что неуправляемые ресурсы создаются в результате прямого вызова API операционной системы с помощью PInvoke (Platform Invocation – обращение к платформе) или с помощью некоторых довольно сложных сценариев взаимодействия COM. С учетом этого возникает следующее правило сборки мусора.
• Правило. Необходимость переопределения Finalize() может возникать только тогда, когда класс C# использует неуправляемые ресурсы посредством PInvoke или при решении сложных задач взаимодействия с COM-объектами (обычно с применением типа System.Runtime.InteropServices.Marshal).
Замечание. В главе 3 уже отмечалось, что не допускается переопредешть Finalize() с типами структуры. Теперь это совершенно ясно, поскольку структуры являются типами, характеризуемыми значениями, и они не размещаются в динамической памяти.
Переопределение System.Object.Finalize()
В тех редких случаях, когда воздается C#-класс, использующий неуправляемые ресурсы, нужно гарантировать, что соответствующая память будет обрабатываться прогнозируемым образом. Предположим, что вы создали класс MyResourceWrapper, использующий неуправляемый ресурс (каким бы этот ресурс ни был), и вы хотите переопределить Finalize(). Немного странно, но в C# вы не можете для этого использовать ключевое слово override.
