Текст книги "Программирование мобильных устройств на платформе .NET Compact Framework"

Автор книги: Иво Салмре

сообщить о нарушении

Текущая страница: 9 (всего у книги 69 страниц)

Управление памятью и сборка мусора

В процессе своего обычного выполнения ваш код периодически инициирует загрузку определений типов в память, компиляцию и выполнение кода, а также размещение объектов в памяти и их удаление из памяти. .NET Compact Framework проектировалась таким образом, чтобы обеспечить наилучший баланс между скоростью запуска, устойчивостью и непрерывностью выполнения кода даже в условиях существования жестких ограничений на объем доступной памяти. Для достижения этой цели загрузчик классов, механизм JIT-компиляции, а также модули распределения памяти и сборки мусора работают скоординированным образом.

Вероятнее всего, выполнение вашего кода будет сопровождаться периодическим созданием новых объектов и их последующим уничтожением после того, как необходимость в них исчезает. Эффективное удовлетворение запросов памяти для размещения объектов и ее освобождение достигаются в .NET Compact Framework за счет утилизации освобождаемой памяти путем так называемой "сборки мусора" (garbage collection). Операции по сборке мусора в той или иной форме используются в большинстве современных сред выполнения управляемого кода.

Сборка мусора в основном предназначена для решения двух задач: 1) восстановления памяти, которая больше не используется, и 2) уплотнения участков используемой памяти таким образом, чтобы для вновь распределяемых областей памяти были доступны как можно более крупные блоки. Тем самым решается одна из наиболее распространенных проблем, которая называется фрагментацией памяти. По своей сути эта проблема аналогична проблеме фрагментации дискового пространства. Если дисковое пространство периодически не реорганизовывать, то по прошествии некоторого времени оно дезорганизуется и разобьется на ряд чередующихся свободных и занятых участков небольшого размера; эти участки и являются фрагментами. Можно считать, что здесь мы имеем дело с проявлением действия закона увеличения энтропии применительно к дисковому пространству и памяти; для того, чтобы обратить энтропийные эффекты, необходимо затратить определенную работу. В результате фрагментации доступ к данным замедляется, поскольку в процессе чтения файлов головкам приходится многократно перемещаться вдоль поверхности диска. Фрагментация памяти оборачивается еще худшими бедами, так как для размещения объектов требуются достаточно большие непрерывные блоки памяти, способные уместить целиком все данные, относящиеся к объекту. После выполнения многочисленных операций выделения и освобождения порций памяти различного размера свободные области оказываются расположенными вразброс, а их размеры являются недостаточными, чтобы обеспечивалось наличие больших непрерывных участков памяти, необходимых для размещения объектов. Уплотнение всей используемой, но расположенной вразброс памяти позволяет создавать крупные блоки свободной памяти, которую можно эффективно использовать при распределении памяти для вновь создаваемых объектов.

Восстановление памяти является сравнительно несложным процессом. Выполнение кода временно прекращается, а активные (live) объекты (то есть объекты, к которым ваш код может осуществлять непосредственный или косвенный доступ) отыскиваются и рекурсивно помечаются. Так как остальные объекты, находящиеся в памяти, уже недоступны активному коду, они остаются непомеченными, что позволяет идентифицировать их как "мусор" и восстановить соответствующую память. Такая разновидность сборки мусора известна под названием "отслеживание и очистка" ("mark and sweep"). Обычно эта операция осуществляется довольно быстро.

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

Однако в рукаве у .NET Compact Framework наряду с JIT-компилятором, диспетчером памяти и сборщиком мусора спрятан еще один козырь: возможность очищать память от пассивного (dead) JIT-компилированного кода. Обычно это делать нежелательно, но при определенных обстоятельствах такая возможность становится незаменимой. Если уж исполнительный механизм, обеспечивая максимальную производительность, потрудился и выполнил JIT-компиляцию управляемого кода до собственных команд процессора, то отбрасывание JIT-компилированного кода могло бы показаться расточительством, поскольку когда в следующий раз возникнет необходимость в выполнении этого кода, то потребуется его повторная JIT-компиляция. В то же время, наличие такой возможности оборачивается благом в следующих двух случаях:

1. Когда приложение осуществило JIT-компиляцию и был выполнен большой объем кода, который в ближайшее время не будет вновь выполняться. Довольно часто ситуации подобного рода возникают в тех случаях, когда выполнение приложения происходит в несколько стадий. Вполне возможно, что код, запускаемый на начальной стадии выполнения приложения для инициализации или настройки объектов и данных, впоследствии повторно выполняться не будет. Если возникает необходимость в дополнительном распределении памяти, то имеется полный смысл использовать для этого память, в которой хранится данный код.

2. Когда набор хранящихся в памяти активных объектов становится настолько большим, что возникает риск аварийного завершения выполнения приложения, если для размещения дополнительных объектов, которые в соответствии с алгоритмом должны создаваться в ходе нормального выполнения приложения, не найдется достаточно большого объема свободной памяти. В этом случае исполнительный механизм будет вынужден вытеснять из памяти и периодически перекомпилировать необходимый приложению код лишь для того, чтобы приложение было в состоянии продолжать дальнейшее выполнение. Если другой возможной альтернативой является только прекращение выполнения приложения из-за нехватки памяти, то единственным решением может быть лишь очистка памяти от JIT-компилированного кода, даже если это означает дополнительные затраты времени на последующую повторную компиляцию этого кода.

Краткий обзор методов управления памятью и сборки мусора

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

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

Рис. 3.2. Упрощенное схематическое представление состояния памяти приложения в процессе выполнения

Таблица 3.1. Условные графические обозначения, используемые на рис. 3.2, 3.3 и остальных рисунках

Темно-серые овалы	Используемые в настоящее время объекты (например, объект Obj12 на рис. 3.2).
Белые овалы	Пассивные объекты. Эти объекты (например, объект Obj6 на рис. 3.2) являются "мусором", к которому у приложения больше нет доступа и от которого можно избавиться с целью высвобождения дополнительной памяти.
Темно-серые прямоугольники	Описания классов и типов, которые были загружены в память по той причине, что к типам осуществлял доступ выполняющийся код.
Внутренние прямоугольники	Код, содержащийся в классах. (Код целиком находится внутри класса.)
Темно-серые внутренние прямоугольники	Код, подвергнутый JIТ-компиляции, поскольку метод был вызван хотя бы один раз (например, код Code1 класса ClassXYZ на рис.3.2).
Светло-серые внутренние прямоугольники	Код, который еще не подвергался JIТ-компиляции. По сравнению с прямоугольниками JIТ-компилированного кода эти прямоугольники имеют меньшие размеры, ибо еще не скомпилированные методы (например, метод Code4 класса XYZ на рис. 3.2) занимают в памяти очень мало места.

Приведенную на рис. 3.2 схему можно прокомментировать следующим образом:

■ Размеры отдельных элементов схемы выбраны таким образом, чтобы они давали представление об относительных объемах используемой памяти. Визуально большие классы и типы используют больше памяти по сравнению с визуально меньшими, поскольку содержат больше "начинки". Объекты различных типов используют различные объемы памяти. Пассивные объекты занимают память до тех пор, пока не будет выполнена операция сборки мусора. Методы, не подвергавшиеся JIТ-компиляции, занимают в памяти очень мало места.

■ В память загружаются описания всех типов и классов, которые используются в вашем приложении. Для различных типов и классов требуются различные объемы памяти.

■ JIT-компиляции подвергаются методы класса, которые вызывались хотя бы один раз. Пример: JIT-компиляции подвергались коды Code1, Code2, Code3 и Code7 класса ClassXYZ.

■ Те методы классов, которые еще не вызывались, не компилируются и поэтому не занимают много места в памяти. Пример: методы Code4 и Code5 класса XYZ еще не подвергались JIТ-компиляции. Как только они будут вызваны, будет осуществлена их JIT-компиляция и произведено распределение памяти для откомпилированного кода.

■ Объекты представляют собой экземпляры типов и классов и требуют места в памяти.

■ "Активные (live) объекты" – это объекты, к которым ваш код может получить доступ путем непосредственного или опосредованного использования глобальных, статических и стековых переменных.

■ "Пассивные (dead) объекты" – это объекты, доступ к которым со стороны вашего приложения стал уже невозможным, но которые еще не были удалены из памяти исполнительным механизмом. Таковыми на рис. 3.2 являются объекты Obj 3, Obj 6, Obj 9 и Obj11. До тех пор пока эти объекты не будут удалены, они будут занимать память подобно активным объектам или JIT-компилированному коду.

По мере того как объекты и другие типы, для которых память распределяется из кучи, будут создаваться вашим приложением и впоследствии становиться ненужными, наступит такой момент, когда невозможно будет создать никакой другой дополнительный объект, не удалив из памяти пассивные объекты. Как только это произойдет, исполнительный механизм инициирует сборку мусора. Состояние памяти приложения непосредственно перед выполнением операции сборки мусора показано на рис. 3.3.

По окончании сборки мусора становится возможным уплотнение активных объектов в памяти. Удаление пассивных объектов из памяти с последующим уплотнением активных объектов во многих случаях позволяет сформировать непрерывные свободные участки памяти большого размера, которые могут быть использованы при создании новых объектов. Состояние памяти приложения непосредственно после выполнения операций сборки мусора и уплотнения объектов показано на рис. 3.4.

Рис. 3.3. Состояние памяти приложения непосредственно перед сборкой мусора

Рис. 3.4. Пассивные объекты удалены из памяти, а активные – уплотнены

В состоянии нормального устойчивого выполнения приложение периодически создает объекты и избавляется от них. В необходимых случаях исполнительный механизм осуществляет сборку мусора и уплотняет память, освобождая ее для размещения вновь создаваемых объектов. Типичное состояние памяти приложения в условиях сосуществования активных и пассивных объектов, а также JIT-компилированного и некомпилированного кода показано на рис. 3.5.

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

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

Рис. 3.5. Типичное состояние памяти приложения при его устойчивом выполнении

Рис. 3.6. Типичное состояние памяти приложения при его устойчивом выполнении непосредственно после сборки мусора

Рис. 3.7. Активные объекты, занимающие всю доступную память

.NET Compact Framework справляется с подобными ситуациями, освобождая большие количества памяти, занимаемой текущим JIT-компилированным кодом. Может быть сброшен любой код, не выполняющийся в данный момент с использованием стека (или стеков, если речь идет о многопоточном выполнении). Это позволяет востребовать обратно память и использовать ее для нужд приложения, связанных с необходимостью размещения новых объектов или JIT-компиляции нового кода в случае, если метод ранее не выполнялся, но теперь вызывается. Состояние памяти приложения после отбрасывания ранее JIT-компилированного кода и сборки мусора показано на рис. 3.8.

Удаление JIT-компилированного кода является серьезным шагом, ибо часть этого кода придется JIT-компилировать повторно, но эта мера может оказаться весьма эффективной, если значительная часть ранее JIT-компилированного кода больше не потребуется для выполнения приложения. Это часто имеет место в тех случаях, когда заметная доля кода приходится на "начальный" код, используемый лишь для настройки последующего выполнения, или когда приложение разделяется на логические блоки, которые не обязательно должны выполняться все одновременно. Состояние памяти приложения вскоре после того, как отброшен весь возможный JIT-компилированный код, показано на рис. 3.9. Последующее размещение новых объектов и повторная JIT-компиляция кода методов осуществляются по мере необходимости.

Рис. 3.8. Удаление ранее JIT-компилированного кода и освобождение памяти, которая ранее была занята JIT-компилированным кодом методов

Рис. 3.9. Методы подвергаются повторной JIT-компиляции по мере их вызова, новые объекты размещаются в памяти, а отбрасываемые объекты становятся "мусором"

Производительность может резко снизиться, если приложение продолжает размещать в памяти все новые и новые объекты, не освобождая ее от старых. Такая ситуация будет приводить к возникновению условий, при которых единственное, что удается удерживать в памяти, – это активные объекты и код, непосредственно указанные в стеке приложения (или стеках, если речь идет о многопоточном выполнении). В этом случае обычный код должен непрерывно подвергаться JIT-компиляции и освобождать память, когда необходимость в нем отпадает, поскольку для хранения JIT– компилированного кода доступна лишь небольшая часть памяти системы. Таким образом, системе приходится выполнять много лишней работы, то есть она, как принято говорить, "молотит впустую", поскольку и приложение, и среда времени выполнения работают на полную мощность с низкой эффективностью лишь для того, чтобы поддерживать возможность выполнения кода небольшими порциями. По мере асимптотического приближения приложения к этому состоянию его производительность резко падает. Возникновения таких состояний следует избегать! Пример приложения, оказавшегося в подобном состоянии, проиллюстрирован на рис. 3.10.

Рис. 3.10. Чрезмерно интенсивная загрузка памяти. Активные объекты занимают всю доступную память даже после того, как она максимально освобождена от JIT-компилированного кода

Резюме

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

Библиотеки классов, поставляемые в составе .NET Compact Framework версии 1.1, могут быть условно разбиты на пять логических блоков: 1) пользовательский интерфейс и поддержка графики, 2) поддержка XML, 3) поддержка клиентов Web-служб, 4) поддержка доступа к данным и всей связанной с этим функциональности, и 5) библиотеки базовых классов. Библиотеки базовых классов проектировались таким образом, чтобы разработчики приложений для настольных компьютеров чувствовали себя комфортно и уверенно при написании кодов для устройств; они должны найти здесь все средства, наличие которых могли ожидать. Сочетание указанных библиотек предоставляет разработчикам богатую палитру функциональных возможностей, которые позволяют создавать приложения коммерческого, производственного, научного и развлекательного характера. По всей видимости, в будущих версиях .NET Compact Framework будет добавлена поддержка моделей, обеспечивающих безопасность доступа кода, а также поддержка мультимедийных средств.

При создании приложений, предназначенных для выполнения в управляемых средах, особенно на мобильных устройствах, полезно иметь общее концептуальное представление о том, каким образом в таких средах осуществляется управление памятью и выполнением приложения. В .NET Compact Framework предлагается JIT-компиляция кода, а также освобождение памяти, используемой приложением, от "мусора". При нормальном выполнении приложения в очистке от "мусора" и периодическом уплотнении нуждается лишь память, занимаемая объектами. Если же необходимость в свободном пространстве возникает в условиях интенсивной загрузки памяти, то операции освобождения памяти и сборки мусора могут применяться также по отношению к JIT-компилированному коду. Аналогично тому, как в случае приложений, основанных на собственных кодах, возможно исчерпание памяти, серьезные проблемы, связанные с перерасходом памяти, могут возникать и в управляемых средах. Это происходит тогда, когда приложение исчерпывает всю доступную память в процессе размещения объектов. В подобных случаях производительность приложения резко падает, поскольку сборщик мусора постоянно пытается освобождать для вновь возникающих нужд память, острая нехватка которой становится все ощутимее. Если необходимую память распределить не удается, приложение завершается аварийно. Ситуаций, в которых возникает острая нехватка памяти, следует избегать, и в последующих главах книги значительная доля внимания будет уделена обсуждению того, как проектировать алгоритмы и создавать приложения, способные эффективно работать с такими ресурсами устройств, как память, освобождаемая в результате сборки мусора.

Такие среды времени выполнения управляемого кода, как .NET Compact Framework, предоставляют разработчикам большие преимущества при создании приложений для мобильных устройств. Производительность и надежность управляемых сред времени выполнения, а также богатые библиотеки классов и компоненты, обеспечивающие повторное использование кода, никого не оставят равнодушным. Однако чтобы в полной мере воспользоваться всеми достижениями, реализованные в рамках платформы для мобильных приложений, разработчики должны хорошо понимать на концептуальном уровне, каким образом осуществляется управление памятью и выполнением приложений. Владение этими знаниями в сочетании с учетом специфики устройств позволит вам после приобретения соответствующих технических навыков создавать замечательные мобильные приложения.