Сборка мусора

Виртуальная машина (virtual machine - VM) Dalvik, помимо всего прочего, представляет собой систему управления памятью, которая часто обращается к механизму сборки мусора (garbage collector - GС) для возврата памяти, ранее выделенной из общей памяти, часто называемой просто «кучей» (heap), когда выделенных фрагментов становится слишком много. Каждый процесс - и, соответственно, каждое приложение - обладает собственной виртуальной машиной и собственным механизмом сборки мусора (сборщиком мусора). И даже несмотря на это, приложение способно заполнить всю общую память размещаемыми в ней объектами, которые уже не используются, но удалить их невозможно, вызывая утечки памяти.

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

На протяжении всего времени выполнения приложение постоянно создаёт новые объекты в общей памяти независимо от их области видимости (scope), то есть поля экземпляра объекта и локальные переменные размещаются в памяти абсолютно одинаково. Когда объект перестаёт использоваться, механизм сборки мусора удаляет его, освобождая память для новых объектов. Сборщик мусора может освободить память, только если не осталось ни одной «сильной» ссылки (strong references) на объект или его родителей1. Пока существует хотя бы одна ссылка на объект, он считается достижимым (reachable) и недоступным для механизма сборки мусора. Но как только объект станет недостижимым (unreachable), сборщик мусора сможет фина- лизировать (finalize) его и освободить ранее выделенную память. Если объект остаётся достижимым, по фактически уже никем не используется, сборщик мусора не сможет освободить память, выделенную этому объекту. В конце концов, подобные утечки могут привести к исчерпанию свободной памяти в приложении, после чего процесс принудительно завершится с исключением java.lang.OutOfMemoryError.

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