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

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

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

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