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

Хотя это только базовый шаблон, для более сложных ситуаций может оказаться нелегко выяснить первопричину утечки. Распространенной практикой по написанию объектно‑ориентированного 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>

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