Модель автоматической утилизации динамической памяти, основанная на сборке мусора. Проблема недетерминизма.

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

Эта работа периодически выполняется «сборщиком мусора» и происходит в две фазы. Сначала «сборщик мусора» находит все достижимые по ссылкам объекты и помечает их. Затем он перемещает их в адресном пространстве программы (с соответствующей корректировкой значений ссылок) для устранения фрагментации памяти.

Обход графа достижимых объектов начинается от «корней», к которым относятся все глобальные ссылки и ссылки в стеках имеющихся программных потоков. Анализируя метаданные (информацию о типах данных, которая размещается внутри выполняемых модулей), «сборщик мусора» выясняет, где внутри объектов имеются ссылки на другие объекты. Следуя по этим ссылкам, он обходит все цепочки объектов и выясняет, какие блоки памяти стали свободными. После этого достижимые по ссылкам объекты перемещаются для устранения фрагментации, а ссылки на перемещенные объекты корректируются.

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

По скорости выделения памяти эта модель сравнима со стеком, ведь выделение объекта — это по сути увеличение указателя свободной области памяти на размер размещаемого объекта. Однако по достижении этим указателем определенного предела запускается «сборка мусора», которая может потребовать много времени и привести к ощутимой задержке в работе программы. Моменты наступления таких задержек и их длительность обычно непредсказуемы. Поэтому одна из проблем «сборщика мусора» — это недетерминизм связанных с его работой задержек.

Для амортизации задержек в «сборщиках мусора» применяются различные подходы. Например, в среде .NET используется принцип поколений, основанный на том наблюдении, что объекты, создаваемые раньше, как правило, живут дольше. Вся память делится на поколения (их количество обычно соответствует числу уровней кэширования с учетом ОЗУ; в современных архитектурах обычно три поколения). Нулевое (младшее) поколение — самое маленькое по объему, первое поколение в несколько раз больше, чем нулевое, а второе в несколько раз больше, чем первое. Объекты создаются в младшем поколении и перемещаются в старшие поколения, пережив «сборку мусора». Последняя выполняется не во всей памяти, а лишь в тех поколениях, в которых исчерпалось свободное место, — чаще в нулевом, реже в первом и еще реже во втором поколении. Таким образом, задержек при «сборке мусора» много, но их средняя длительность небольшая [2].

Другой подход к амортизации задержек используется в «сборщиках мусора» реального времени среды Java (JRTS — Java Real-Time Specification). В них дефрагментация выполняется эпизодически и лишь в самом крайнем случае, когда не может быть найден свободный блок памяти нужного размера. Кроме того, «сборка мусора» выполняется в течение фиксированных интервалов времени (квантов), которые обязательно чередуются с квантами работы программы [3].

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

Для решения указанной проблемы в среде .NET используется детерминированное завершение жизни объектов через интерфейс IDisposable. Этот интерфейс имеет единственный метод Dispose, который реализуется в объектах, управляющих ресурсами. Метод Dispose, как правило, освобождает ресурсы и отменяет работу процедуры-завершителя (метода Finalize), чтобы ускорить освобождение памяти. После вызова метода Dispose объект не уничтожается, а остается в памяти до тех пор, пока не пропадут все ссылки на него.

Применение интерфейса IDis-posable на практике выявило новые проблемы. Оказалось, что после вызова метода Dispose в программе могут оставаться ссылки на объект, находящийся уже в некорректном состоянии. Программе никто не запрещает обращаться по этим физически доступным, но логически «зависшим» ссылкам и вызывать у некорректного объекта различные методы. Метод Dispose может вызываться повторно, в том числе рекурсивно. Кроме того, в программе с несколькими вычислительными потоками может происходить асинхронный вызов метода Dispose для одного и того же объекта.

Для решения проблем этого метода программистам было предписано делать следующее: 1) определять в объекте булевский флаг, позволяющий выяснить, работал ли в объекте код завершения; 2) блокировать объект внутри метода Dispose на время работы кода завершения; 3) игнорировать повторные вызовы метода Dispose, проверяя упомянутый булевский флаг; 4) в начале public-методов проверять, находится ли объект уже в завершенном состоянии, и если это так, то создавать исключение класса ObjectDisposedException.

Еще одна серьезная проблема — это легальная «утечка памяти». Если в модели с ручным освобождением объектов «утечка памяти» возникает из-за невыполненных операторов delete, то в модели с автоматической «сборкой мусора» — из-за невыполненного обнуления ссылок. Такой вид «утечек памяти» характерен для программного кода, в котором одними объектами регистрируются обработчики событий в других объектах. Программисты порой забывают отключать обработчики событий, в результате ассоциированные объекты остаются в памяти, несмотря на кажущееся отсутствие ссылок на них в программе.