От редакции

Динамически занимаемая память в приложениях - сегодня и завтра

После взгляда на оглавление этого номера журнала у среднего читателя вполне может создаться ощущение, что и редакция, и авторский коллектив испытывают какой-то нездоровый интерес к теме управления динамической памятью. А если вспомнить, что и в пилотном выпуске RSDN Magazine была статья аналогичной тематики ("Поиск потерянных блоков памяти с помощью ascLib"), то картина и впрямь складывается какая-то клиническая...

Все проще (и, одновременно, все сложнее).

При рассмотрении (особенно в периодике) вопросов программирования на уровне программ типа "Hello, World!" эти вопросы, как правило, остаются "за бортом". В недавнем прошлом для многих это вообще не было проблемой. Программисты для DOS вырастали в слепой уверенности, что вся не освобожденная ими динамическая память все равно будет возвращена системе после выхода из программы (да так оно и было). Ошибки в стратегии выделения памяти мешали работе только самого "глючного" приложения, а перезагрузка системы была привычным и нужным действием.

Однако уже тогда мир Unix жил немного иначе. Работающие месяцами (а то и годами) фоновые процессы, или демоны, не имели права бесконтрольно тратить системную память. Если при написании такой программы забыть вернуть несколько байт в критическом месте, то вскоре "зарвавшийся" процесс будет тактично отлучен от общей кормушки, а пользователи быстро выяснят, чье творение ведет себя так не по-соседски. Представлять же себе другие последствия человеческой рассеянности - например, программу контроля параметров ядерного реактора, в которой при каждой проверке температуры остается на 20 байт меньше свободной памяти - право, не хочется...

С приходом Windows в мир серверных систем эти вопросы встали и перед тысячами других разработчиков.

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

Другое решение, которое все настойчивее стремится занять нишу надежных средств для разработчиков - автоматическое управление памятью. Теперь и долгожданная технология .NET от Microsoft включилась в эту борьбу. "Сборка мусора" (Garbage Collection, GC) на уровне языка, на первый взгляд, решает все проблемы надежного контроля над освобождением ставших ненужными блоков памяти. Однако и этот подход нуждается в знании механизмов реализации GC в разных средах.

В следующем разделе собраны вместе несколько "хиповых" статей (не путать с "хитовыми" - хотя нам бы этого также хотелось добиться) - то есть статей, посвященных разным аспектам использования и реализации хипов. Слово heap на русский переводят обычно как <куча>, но этот термин как-то недостаточно наукообразен. Лучше сказать, что хип - это большая область памяти, используемая для динамического занятия и освобождения большого количества блоков памяти программой. Хип используется, если количество и размер объектов, нужных программе, не известны заранее, или если объекты слишком велики, чтобы поместиться в стеке.

Для изучающих технологию .NET предназначена статья Игоря Ткачева "Автоматическое управление памятью в .Net". А для C++-программистов предназначен интересный материал Михаила Чащина "Реализация сборки мусора на С++".

Безошибочного вам программирования!


Эта статья опубликована в журнале RSDN Magazine . Информацию о журнале можно найти здесь