Замыкания и утечки памяти

В этом разделе речь идет, преимущественно, об Internet Explorer и его скриптовом движке — JScript. Однако, во-первых, многие из приведенных методик и советов имеют большое значение для других браузеров и их виртуальных JavaScript-машин. Во-вторых, IE на данный момент занимает порядка 60% пользовательской аудитории, поэтому при рассмотрении эффективного программирования на JavaScript выбрасывать его из поля зрения было бы, по меньшей мере, глупо.

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

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

Хорошей новостью будет то, что шаблоны утечек памяти могут быть легко обнаружены, если знать, где их искать. Методы устранения наиболее тяжелых из них подробно описаны, и они требуют лишь небольшого количества дополнительных усилий. Хотя некоторые страницы могут по-прежнему «падать» из-за небольших утечек, самые значительные утечки могут быть легко удалены.

Шаблоны утечек

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

Основные виды утечек можно разбить на следующие 4 типа.

1. Циклические ссылки, когда существует взаимная ссылка между DOM-объектом в браузере и скриптовым движком. Такие объекты могу приводить к утечкам памяти. Это самый распространенный шаблон.

2. Замыкания являются самым значимым шаблоном для существующих архитектур веб-приложений. Замыкания довольно легко зафиксировать, потому что они зависят от ключевого слова, относящегося к используемому скриптовому языку, и могут быть по нему, в общем случае, обнаружены.

3. Постраничные утечки зачастую представляют собой очень маленькие утечки, которые возникают из-за учета объектов при перемещении от элемента к элементу. Ниже будет рассмотрен порядок добавления DOM-объектов, а заодно и характерные примеры, которые демонстрируют, как небольшое изменение вашего кода может предотвратить создание таких учитываемых объектов.

4. Псевдо-утечки, по существу, не являются утечками, но могут вызывать некоторое беспокойство, если не понимать, куда расходуется память. Будет рассмотрена перезапись объекта скрипта и как она проявляется в расходовании очень малого количества памяти, если работает так, как требуется.

Циклические ссылки

Циклические ссылки являются источником практически любой утечки. Обычно скриптовые движки нормально отрабатывают с циклическими ссылками при помощи собственных сборщиков мусора, однако из-за некоторых неопределенностей их механизм эвристических правил может дать сбой. Одной из таких неопределенностей будет состояние DOM-объекта, к которому имеет доступ текущая порция скрипта. Основной принцип в данном случае можно описать так:

Рис. 35. Основной шаблон циклической ссылки

Утечка в таком шаблоне происходит из-за особенностей учета DOM-ссылок. Объекты скриптового движка удерживают ссылку на DOM-элемент и ожидают, пока будут освобождены все внешние ссылки, чтобы освободить, в свою очередь, этот указатель на DOM-элемент. В нашем случае у нас две ссылки на объект скрипта: внутри области видимости скриптового движка и от расширенного свойства DOM-элемента. По окончанию своей работы скрипт освободит первую ссылку, но ссылка из DOM-элемента никогда не будет освобождена, потому что ждет, что это сделает объект скрипта!

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

Стоит посмотреть, как данный шаблон будет выглядеть в HTML. Это может вызвать утечку, используя глобальную переменную и DOM-объект, как показано ниже.

<script type=‖text/javascript‖>
    var myGlobalObject; 
    function SetupLeak() { 
    // Для начала создадим ссылку из скрипта на DOM-элемент 
        myGlobalObject = document.getElementById("LeakedDiv"); 
    // Потом установим ссылку из DOM на глобальную переменную 
        document.getElementById("LeakedDiv").expandoProperty = myGlobalObject; 
    }
     function BreakLeak() { 
        document.getElementById("LeakedDiv").expandoProperty = null; 
    } 
    window.onload = SetupLeak; 
    window.onunload = BreakLeak;
</script>

Чтобы разрушить этот шаблон, можно использовать явное присвоение null тому свойству, которое «течет». Таким образом, при закрытии документа мы сообщаем скриптовому движку, что между DOM-элементом и глобальной переменной нет больше никакой связи. В результате все ссылки будут очищены, и сам DOM-элемент будет освобожден. В таком случае веб-разработчик знает больше о внутренних отношениях между объектами, чем сам скрипт, и может поделиться этой информацией со скриптом.

Более сложный случай

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

<script type=‖text/javascript‖>
    function Encapsulator(element) { 
    // Создаем элемент 
        this.elementReference = element; 
    // Создаем циклическую ссылку 
        element.expandoProperty = this; 
    }
     function SetupLeak() { 
    // Утечка: все в одном 
        new Encapsulator(document.getElementById("LeakedDiv")); 
    }
     function BreakLeak() {
         document.getElementById("LeakedDiv").expandoProperty = null; 
    } 
    window.onload = SetupLeak; 
    window.onunload = BreakLeak;
</script>
<div id="LeakedDiv"></div>

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