Балансировка ресурсов в языке Java

В отличие от C++ язык Java реализует «ленивую» форму автоматического разрушения объекта. Объекты, ссылки на которые отсутствуют, считаются кандидатами на попадание в «мусор», и их метод finalize будет вызываться в любой момент, когда процедура сборки мусора будет претендовать на эти объекты. Представляя собой удобство для разработчиков, которым больше не приходится жаловаться на утечки памяти, в то же время он усложняет реализацию процедуры очистки ресурсов по схеме С + +. К счастью, разработчики языка Java глубокомысленно ввели компенсирующую языковую функцию – предложение finally. Если блок try содержит предложение finally, то часть программы, относящаяся к этому предложению, гарантированно исполняется только в том случае, если исполняется любая инструкция в блоке try. Неважно, возбуждается при этом исключение или нет (даже при выполнении оператора return программой в блоке try) – программа, относящаяся к предложению finally, будет выполнена. Это означает, что использование ресурса может быть сбалансировано с помощью программы типа:

public void doSomething() throws IOException {

File tmpFile = new File(tmpFileName);

FileWriter tmp = new FileWriter(tmpFile);

try {

// do some work

}

finally {

tmpFile.delete();

}

}

Подпрограмма использует промежуточный файл, который мы хотим удалить, независимо от того, как подпрограмма заканчивает свою работу. Блок finally позволяет нам выразить это в сжатой форме.

Случаи, при которых балансировка ресурсов невозможна

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

Хитрость здесь состоит в установлении семантического инварианта для выделения памяти. Необходимо решить, кто несет ответственность за данные в составной структуре. Что произойдет при освобождении структуры верхнего уровня? Есть три основных варианта развития событий:

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

2. Структура верхнего уровня просто освобождается. Любые структуры, на которые она указывает (и на которых нет других ссылок), становятся "осиротевшими".

3. Структура верхнего уровня отказывается освобождать себя, если в нее входят какие-либо подструктуры.

В этом случае выбор зависит от условий, в которых находится каждая взятая в отдельности структура данных. Однако этот выбор должен быть явным для каждого случая, и ваше решение должно реализовываться последовательно. Реализация любого из представленных вариантов на процедурном языке программирования типа С может представлять проблему: структуры данных сами по себе не являются активными. В этих условиях для каждой из основных структур предпочтительнее написать модуль, обеспечивающий стандартные средства распределения и освобождения. (Этот модуль также обеспечивает распечатку результатов отладки, преобразование в последовательную и параллельную формы и средства обхода.)

И наконец, если отслеживание ресурсов становится слишком хитрой процедурой, можно создать собственную форму ограниченной автоматической сборки «мусора», реализуя схему подсчета ссылок для ваших динамически распределенных объектов. В книге "More Effective С++" ([Меу9б]) этой теме посвящен целый раздел.

Проверка баланса

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

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

При работе на более низком (но не менее полезном) уровне можно потратиться на инструментальные средства, которые (помимо всего прочего) проверяют выполняемые программы на наличие утечек памяти (регулярного неосвобождения области памяти). Весьма популярными являются Purify (www.rational.com) и Insure++ (www.parasoft.com).

Другие разделы, относящиеся к данной теме:

• Проектирование по контракту

• Программирование утверждений

• Несвязанность и закон Деметера

Вопросы для обсуждения

• Несмотря на то, что не существует надежных способов удостовериться в том, что вы освободили ресурсы, в этом могут помочь некоторые технологии проектирования, если их применять последовательно. В данной главе обсуждалось, как установить семантический инвариант, с тем чтобы основные структуры данных могли управлять освобождением памяти. Подумайте, как с помощью принципа "Проектирование по контракту" можно было бы усовершенствовать эту идею.

Упражнения

22. Некоторые разработчики программ на С и С++ обращают особое внимание на необходимость установки указателя в NULL после освобождения области памяти, на которую он ссылается. Почему это можно считать удачной идеей? (Ответ см. в Приложении В.)

23. Некоторые разработчики программ на языке Java обращают особое внимание на необходимость установки объектной переменной в NULL после окончания использования объекта. Почему это можно считать удачной идеей? (Ответ см. в Приложении В.)

Глава 5

Гибкость против хрупкости

Жизнь не стоит не месте.

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

В разделе «Обратимость» говорится об опасностях необратимых решений. Мы расскажем вам, как принимать обратимые решения так, чтобы ваша программа смогла остаться гибкой и адаптируемой перед лицом нашего неопределенного мира.

В начале необходимо рассмотреть связывание – взаимозависимость между модулями программы. В разделе "Несвязанность и закон Деметера" будет показано, как сохранить отдельные концепции и уменьшить связывание.

Хороший способ сохранить гибкость – это писать программы меньшего размера. Изменение кода открывает перед вами возможность внесения новых дефектов. В разделе «Метапрограммирование» объясняется, как полностью вывести из текста программы подробности в то место, где их можно изменить безопаснее и проще.

В разделе "Временное связывание" рассматриваются два временных аспекта применительно к связыванию. Зависите ли вы от того обстоятельства, что «тик» наступает раньше, чем «так»? Если вы хотите сохранить гибкость, то нет!

Ключевым принципом в создании гибкой программы является отделение модели данных от их визуального представления, или воспроизведения. Несвязанность модели и ее визуального представления описана в разделе "Всего лишь визуальное представление".

И наконец, существует методика несвязанности модулей в еще большей степени за счет предоставления "места встречи", где модули могут обмениваться данными анонимно и асинхронно. Эта тема освещена в разделе "Доски объявлений".

Взяв эти методики на вооружение, вы можете написать программу, которая будет энергично вращаться – как в рок-н-ролле.