Необходимость автоматических методов

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

Предыдущее обсуждение достаточно ясно показало, как важно иметь возможность управлять памятью. По словам Михаила Швейцера (Michael Schweitzer) и Ламберта Стретра (Lambert Strether): "ОО-программа без автоматического управления памятью то же самое, что скороварка без клапана безопасности: рано или поздно она взорвется!" (Из [Schweitzer 1991])

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

При выборе ОО-среды - или просто компилятора ОО-языка - для разработки программного продукта ограничьте ваше внимание только теми решениями, которые предлагают автоматическое управление памятью.

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

Что в точности понимается под восстановлением?

Прежде чем рассмотреть подсчет ссылок и сборку мусора, займемся одной технической деталью. В любой форме автоматического управления памятью возникает вопрос, - каков механизм утилизации объекта, определенного как недостижимый? Возможны две интерпретации:

[x]. Механизм может добавить память, занимаемую объектом, к постоянно поддерживаемому "списку свободных ячеек", в духе техники, использованной при рассмотрении подхода на уровне компонентов. Последующая инструкция создания (create x...) вначале обратится к этому списку для выделения памяти новому объекту. Только если этот список пуст или нет подходящих ячеек, инструкция запросит память у операционной системы. Этот подход может быть назван внутренний список свободной памяти.

[x]. Альтернативой является возвращение занимаемой объектом памяти операционной системе. На практике это решение включает в себя некоторые аспекты первого: для избежания переизбытка системных вызовов, утилизированные объекты могут временно храниться в списке, возвращаемого операционной системе при достижении определенного предела. Этот подход может быть назван реальным восстановлением.

Хотя возможны оба решения, долго работающие системы требуют реального восстановления. Причина очевидна. Рассмотрим приложение, которое никогда не останавливается. Оно создает объекты, большинство из которых становятся недостижимыми. Существует верхняя граница количества одновременно достижимых объектов, в то время как общее количество созданных с начала работы объектов не ограниченно. Тогда при подходе внутренних списков свободной памяти возможна ситуация, когда приложение постоянно запрашивает большую, чем нужно, память. В упражнении У9.1 этой лекции требуется создать образец программы, демонстрирующий такое поведение.

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