Приведенный пример, хотя и важен, но только для специальных случаев. В общем случае приходится отвечать на сложный вопрос - что делать с недостижимыми объектами?
Три ответа
С недостижимыми объектами можно поступать тремя способами:
[x]. Проигнорировать проблему и надеяться, что хватит памяти для размещения всех объектов: достижимых и недостижимых. Это можно назвать несерьезным (casual) подходом.
[x]. Предложить разработчикам включать в каждое приложение алгоритм, ищущий недостижимые объекты, и дать им механизм освобождения соответствующей памяти. Такой подход называется восстановлением вручную(manual reclamation) .
[x]. Включить в среду разработки (как часть исполняемой системы (runtime system)) механизм, автоматически определяющий и утилизирующий недостижимые объекты. Этот подход принято называть автоматической сборкой мусора (automatic garbage collection).
Остаток лекции посвящен этим подходам.
Несерьезный подход (тривиальный)
Первый подход заключается в игнорировании проблемы: предоставлять мертвые объекты их судьбе. Создаются объекты как обычно, но никто не волнуется о том, что может потом случиться с объектами.
Может ли быть оправдан несерьезный подход?
Несерьезный подход не создает проблем в системах, создающих небольшое число объектов, например, при проведении простых тестов и экспериментов.
Более интересен случай, когда система может создавать много объектов, гарантируя, что ни один или немногие из них станут недостижимыми. Этот случай аналогичен статической схеме размещения, в которой ни один объект не удаляется. Разница только в том, что создание происходит динамически во время выполнения программы. Несерьезный подход в этом случае оправдан, поскольку практически не возникает необходимость утилизации объектов.
Некоторые программы реального времени следуют этой схеме: по причине эффективности, создавая все необходимые объекты статично или во время инициализации, избегая непредсказуемых моделей динамического создания.
Этот метод применяется в "жестких" системах реального времени ("hard-real- time"), требующих гарантированное микросекундное время отклика на внешние события (например, системы обнаружения ракет). В таких системах время выполнения каждой операции должно быть полностью предсказуемо. Но тогда приходится отказываться не только от управления памятью, но и от динамического создания объектов, рекурсии, вызова процедур с локальными сущностями и так далее. Работа с такими системами подразумевают специализированную машину с одним исполняемым процессом, фактически без операционной системы в обычном понимании этого термина. В таких средах люди предпочитают писать на языках ассемблера, из-за страха дополнительных неожиданностей от сгенерированного компилятором кода. Все это сводит обсуждение к малой, хотя и стратегически важной области мира программ.
Надо ли заботиться о памяти?
Другой аргумент, который можно услышать в оправдание несерьезному подходу, - это постоянный рост объема доступной памяти компьютера и уменьшение цены памяти.
Используемая память может быть как виртуальной, так и реальной. В системах виртуальной памяти первичная и вторичная память делится на блоки, называемые страницами. Вновь требуемые страницы первичной памяти вытесняют во вторичную память редко используемые страницы первичной памяти. Если такая система используется для работы с ОО-системами, страницы, содержащие недостижимые объекты, будут вытесняться и освободят основную память для часто используемых объектов.
Если бы действительно в нашем распоряжении было почти безграничное количество почти свободной памяти, можно было бы удовлетвориться несерьезным подходом.
К несчастью, это не так.
Первая причина в том, что на практике виртуальная память не эквивалентна реальной. Если хранить большое количество объектов в виртуальной памяти, в которой меньшинство достижимых объектов рассыпано среди большинства недостижимых, то процесс выполнения будет постоянно вызывать перемещение страниц памяти, феномен, известный как пробуксовка (trashing), приводящий к драматическому увеличению времени выполнения. Действительно, системы виртуальной памяти усложняют эффективное разделение двух основных аспектов - пространства и времени. (См. "Эффективность", лекцию 1.)
Но есть более важное ограничение применения несерьезного подхода. Даже большая память имеет границы. Удивительно, как быстро программисты к ним подходят. Как только мы выходим за пределы систем с небольшим числом недостижимых объектов, лицом к лицу сталкиваемся с проблемой восстановления памяти.
Байт здесь, байт там, и реальные покойники
Пора послушать печальную и поучительную историю Лондонской службы скорой помощи.
Лондонская служба скорой помощи, как говорят, самая большая в мире, обслуживает территорию около 1500 кв. км, c постоянным населением почти в семь миллионов человек и с еще большим количеством населения в дневное время. Каждый день эта служба обслуживает пять тысяч пациентов и получает от двух до трех тысяч звонков.
Как можно догадаться по мрачному заголовку, в этой работе используются компьютеры (точнее ПО). Вначале было несколько неудачных разработок, даже не введенных в действие, как несоответствующих требованиям, несмотря на то что на разработку этих систем затрачивались значительные финансовые средства. Наконец, в 1992 была введена в эксплуатацию новая система, разработанная за миллион фунтов. Скоро о ней снова заговорили. 28 и 29 октября на телевидении и в прессе сообщалось, что из-за неадекватной работы системы были потеряны двадцать жизней. Говорили, что в одном конкретном случае врачи скорой помощи по рации сообщили на базу, что прибыли на место назначения и спросили, почему владелец похоронного бюро прибыл раньше. Исполнительный директор службы ушел в отставку, была назначена следственная комиссия.
Служба скорой помощи после трагедии не сразу отказалась от компьютерной системы, а переключилась на гибридную модель - частично ручную, частично полагающуюся на систему. Согласно официальным отчетам:
Эта гибридная система действовала с переменным успехом с 27 октября 1992 г. до раннего утра 4 ноября. Однако после двух часов 4 ноября работа системы значительно замедлилась, вскоре после этого система вышла из строя совсем. Перезагрузка не смогла решить проблему. Управление и персонал вернулись к бумаге и телефонным звонкам.
Что привело систему к краху, так что ее не могли сохранить даже как дополнение к ручным операциям? Отчет определил несколько причин. Вот основная:
Следственная команда пришла к выводу, что крах системы был вызван незначительной ошибкой программного обеспечения. Программист XX ("XX" здесь и далее заменяет название компании, разрабатывающей программное обеспечение данной системы) тремя неделями раньше оставил в системе кусок программного кода, который, используя небольшой файл на сервере, записывал и не стирал информацию о выезде машины на вызов. Через три недели память переполнилась. Эта ошибка была вызвана беспечностью и отсутствием проверки качества программного кода. Такого рода неисправности вряд ли могут быть обнаружены обычным тестированием программистом или пользователем.