Опубликован: 17.10.2005 | Доступ: свободный | Студентов: 8823 / 588 | Оценка: 4.38 / 4.10 | Длительность: 41:16:00
ISBN: 978-5-7502-0255-3
Специальности: Программист
Лекция 9:

Управление памятью

Практические проблемы сборки мусора

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

Класс MEMORY

Наиболее удобный подход - представить эти свойства в виде класса, который назовем MEMORY. Класс приложения, нуждающийся в свойствах, будет наследником MEMORY.

Аналогичный подход будет использован для механизма обработки исключений (класс EXCEPTIONS, "Когда контракт нарушается: обработка исключений" ) и для управления параллелизмом (класс CONCURRENCY, лекция 12 курса "Основы объектно-ориентированного проектирования")

Среди компонентов класса MEMORY будут представлены рассмотренные ранее процедуры: collection_off, collection_on, collect_now.

Механизм освобождения

Другой важной процедурой класса MEMORY является dispose (не путайте с тезкой Pascal, которая освобождает память). Она связана с важной практической проблемой, иногда называемой финалом или окончательным завершением (finalization). Если сборщик мусора утилизирует объект, связанный с внешними ресурсами, вы можете пожелать включить в его спецификацию некоторое дополнительное действие, такое как освобождение ресурсов, выполняемое параллельно с утилизацией. Типичный пример - класс FILE, экземпляр которого представляет файлы операционной системы. Желательно иметь возможность в случае утилизации недостижимого экземпляра класса FILE вызвать некоторую процедуру, закрывающую соответствующий физический файл.

Обобщая сказанное, рассмотрим процедуру dispose, выполняющую во время утилизации необходимые объекту операции. Это могут быть не только операции по освобождению ресурсов, но и любые операции, определяемые спецификацией класса.

При ручном управлении памятью проблем не возникает: достаточно включить вызов dispose до вызова reclaim. Деструктор класса в С++ включает в себя две операции dispose и reclaim. Однако при наличии сборщика мусора приложение напрямую не контролирует момент утилизации объекта, поэтому невозможно вставить dispose в нужное место.

Решение проблемы использует мощь объектной технологии и, в частности, наследование и переопределение. (Эта техника изучается в последующих лекциях, но ее применение здесь достаточно просто и понятно без детального ознакомления.) Класс MEMORY включает процедуру dispose, в теле которой никакие действия не выполняются:

dispose is
            - Действия, которые следует выполнить в случае утилизации;
            - по умолчанию действия отсутствуют.
            - Вызывается автоматически сборщиком мусора.
      do
      end

Тогда любой класс, требующий специальных действий всякий раз, когда сборщик утилизирует один из его экземпляров, должен переопределить процедуру dispose так, чтобы она выполняла эти действия. Например, представим, что класс FILE имеет логический атрибут opened и процедуру close. Он может переопределить dispose следующим образом:

dispose is
            - Действия, которые следует выполнить в случае утилизации:
            - закрыть связанный файл, если он открыт.
            - Вызывается автоматически сборщиком мусора.
      do
         if opened then
               close
         end
      end

Комментарии описывают используемое правило: при утилизации объекта вызывается dispose - либо изначально пустую процедуру (что далеко не самый общий случай), либо версию, переопределенную в классе, представляющего потомка MEMORY.

Александр Шалухо
Александр Шалухо
Анатолий Садков
Анатолий Садков

При заказе pdf документа с сертификатом будет отправлен только сертификат или что-то ещё?