Главная arrow С++ (часть 4) arrow Pro et contra управления памятью вручную

Pro et contra управления памятью вручную

Главное достоинство управления динамической памятью вручную — эффективность. Нет сборщика мусора, не тратится время на отслеживание активных объектов или периодический поиск неиспользуемой памяти. Вместо этого программист явно освобождает выделенную память, когда объект, ее занимавший, перестает использоваться, и нет никаких непроизводительных потерь. Поскольку нет расходов на сбор мусора, управление памятью вручную позволяет создавать более эффективный код. Это одна из причин, по которой в языке С++ поддерживается управление памятью вручную: оно позволяет создавать высокопроизводительный код.
Другое достоинство такого подхода заключается в возможности контроля. Хотя требуемые от программиста как выделение, так и освобождение памяти, обременительны, взамен он получает контроль над обоими этапами процесса. Вы точно знаете, когда память будет выделена, и когда она освободится. Более того, когда вы с помощью операции delete освобождаете память, отведенную объекту, его деструктор выполняется сейчас же, а не спустя какое-то время, как это может быть в случае сбора мусора. Таким образом, в случае управления памятью вручную вы можете проконтролировать уничтожение размещенного ранее объекта.
Несмотря на эффективность, управление распределением динамической памяти вручную чувствительно к весьма досадному типу ошибки: утечке памяти
(memory leak). Поскольку память должна освобождаться вручную, можно (легко) забыть сделать это. В результате память остается выделенной, даже если она больше не нужна. Утечки памяти не могут возникнуть в системе со сбором мусора, потому что сборшик мусора гарантированно периодически освобождает память неиспользуемых объектов. Утечки памяти — весьма серьезная проблема программирования в операционной системе Windows, в которой занятая память медленно снижает производительность системы.
Другие проблемы, связанные с управлением динамической памятью вручную, включают в себя преждевременную очистку памяти, когда она еще используется, и случайное освобождение одного и того же фрагмента дважды. Обе эти ошибки могут привести к серьезным сбоям. К сожалению, они зачастую не проявляются немедленно, что затрудняет их поиск.
Pro et contra сбора мусора
Существует несколько способов реализации сбора мусора разной производительности. Но у всех систем сбора мусора есть общие характеристики, которые позволяют сравнить их с параметрами управления динамической памятью вручную. Главные достоинства сбора мусора — простота и надежность. В среде со сбором мусора вы явно выделяете память с помощью операции new, но никогда явно не освобождаете ее. Занятая память очищается автоматически. Следовательно, нет опасности забыть об уничтожении объекта или удалить его раньше времени. Это упрощает программирование и устраняет целый ряд проблем. Более того, нет возможности освободить динамически выделенную память дважды. Таким образом, сбор мусора обеспечивает легкий в использовании, свободный от ошибок, надежный способ управления динамической памятью.
К сожалению, за простоту и надежность сбора мусора приходится "платить". Первая плата — непроизводительные расходы, связанные с механизмом сбора мусора. Все алгоритмы, реализующие этот механизм, потребляют время процессора, потому что возврат памяти не бесплатный процесс. Таких потерь позволяет избежать лишь способ управления динамической памятью вручную.
Второй взнос — потеря контроля над временем уничтожения объекта. В отличие от управления вручную, при котором объект удаляется (вызывается его деструктор) в известный момент времени, — когда для этого объекта выполняется операция delete — у сбора мусора нет такого четкого и быстрого правила. Напротив, когда применяется сбор мусора, объект не уничтожается до тех пор, пока не запустится сборщик и не освободит память, отведенную объекту, а это событие может не произойти до некоторого произвольно выбранного момента времени в будущем. Например, сборщик может не работать до тех пор, пока количество свободной динамической памяти не сократится до определенного количества. Более того, не всегда можно узнать, в каком порядке сборщик мусора уничтожает объекты. Иногда отсутствие сведений о точном времени удаления объекта может вызвать проблемы, так как ваша программа не знает, когда точно будет вызван деструктор для динамически размещенного объекта.
В системах сбора мусора, которые выполняются как фоновые задачи, потеря контроля может превратиться в более серьезную проблему для некоторых типов приложений, так как вносит существенную неопределенность в поведение программы. Сборщик мусора, работающий в фоновом режиме, освобождает память в моменты времени, заранее не известные. Например, сборщик мусора обычно выполняется только, когда есть свободное время у процессора. Поскольку подобная ситуация возникает в разное время при выполнении различных программ на разных компьютерах и под управлением различных операционных систем, конкретная точка в запущенной программе, в которой выполнится сборщик мусора, неопределима. Во многих программах это не создает проблем, но в приложениях реального времени способно породить хаос, поскольку неожиданное выделение сборщику мусора циклов процессора может вызвать пропуск события в таких программах.