Утечки памяти в программах на Perl

Алексей Мичурин

Все программисты знают, сколько неприятностей могут доставить утечки памяти, как сложно бывает локализовать и устранить их причины. И любой, кто работал с Perl, смог по достоинству оценить систему сборки мусора, которой оснащён интерпретатор этого языка. Она автоматически заботится об удалении данных, которые больше не понадобятся, и защищает таким образом от утечек памяти. У программиста может появиться некая иллюзия неограниченной мощи этого механизма. Но так ли он всемогущ?

Perl – прекрасный язык (и мы сегодня в этом ещё убедимся), позволяющий программисту весьма кратко выразить достаточно ёмкие мысли. Приведу пример программы, состоящей из одной строки и демонстрирующей утечку памяти в Perl:

# ОСТОРОЖНО! УТЕЧКА ПАМЯТИ!

while (1) { my ($a,$b); $a=$b; $b=$a }

Если вы решите испытать эту нехитрую программу, то приготовьтесь к тому, что события будут развиваться стремительно. На моей станции она «съедает» всю память за доли минуты.

В ней, как вы видите, реализован бесконечный цикл. В теле цикла созданы две локальные переменные $a и $b. Ожидается, что, как и положено локальным переменным, они будут уничтожаться каждый раз по окончании выполнения тела цикла, но этого не происходит. Почему?

Причина кроется в устройстве системы сборки мусора. Последняя просто ведёт учёт всех ссылок, сделанных на переменную. Если переменная вышла из области видимости, но ссылки на неё остались, то данные не удаляются (хотя имя переменной становится недоступным). Это обеспечивает работоспособность всех ссылок, но может ввести в заблуждение систему сборки мусора. Обратите внимание, ссылки не анализируются на предмет, будут они удалены в ближайшее время или не будут. Они подсчитываются все без исключения.

Иллюстрацией к сказанному может послужить абсолютно «бытовая» ситуация, встречающаяся сплошь и рядом:

my $ref;

{ my $var=1975; $ref=$var; }

# print $var # неверно, имя $var уже не доступно

print $$ref;

# будет напечатано '1975', данные не исчезли

Как видите, за пределами блока имя $var уже не доступно, но данные, ранее ассоциированные с этим именем, сохранились и будут в сохранности, пока не будет удалена последняя ссылка на них[1].

В нашем однострочном примере переменные $a и $b содержат ссылки друг на друга. Несмотря на то, что их имена становятся не видны сразу по окончании выполнения блока, система сборки мусора не удаляет данные, ассоциированные с ними, неуклонно следуя своему алгоритму: данные считаются «мусором» только в том случае, если ссылок на них не осталось.

Может быть, кому-то покажется, что подобная ситуация попахивает надуманностью и встречается редко? Отнюдь. Например, у вас может быть массив структур[2], описывающих товары, и другой массив структур, описывающих магазины. Структуры, описывающие товары, могут содержать указатели на магазины, а структуры, описывающие магазины, могут ссылаться на элементы списка товаров. Вот мы и получили две конструкции, ссылающиеся друг на друга. Больше того, реляционные базы данных просто-таки сами подсказывают подобные решения.