JQuery утечки решены, но почему?

Я работаю над большим корпоративным приложением с большим количеством JavaScript. Достаточно того, что я не могу пройти и исправить все небольшие круговые ссылки, которые были созданы за последние 5 лет развития. Во время исследования решений я столкнулся с этим небольшим хакером/патчем jQuery:

http://kossovsky.net/index.php/2009/07/ie-memory-leak-jquery-garbage-collector/

и решил попробовать. Удивительно, это работает! sIEVE не показывает утечек в местах, которые я ранее идентифицировал, а задача iexplore поддерживает более управляемый объем памяти.

Мой вопрос: зачем это работает? jQuery.remove вызывает .removeChild, который должен избавиться от элемента, но, по-видимому, этого не делает. Патч вместо этого добавляет целевой элемент в новый div коллектора мусора, который затем очищается. Почему метод удаления патча полностью освобождает память, но функция удаления jQuery не работает? Я надеюсь понять, почему это работает, чтобы, возможно, улучшить решение, прежде чем я проверю его на большее приложение.

Ответ 1

Это метод .remove в текущей версии jQuery (1.6.2). Обратите внимание, что он вызывает .cleanData:

// keepData is for internal use only--do not document
    remove: function( selector, keepData ) {
        for ( var i = 0, elem; (elem = this[i]) != null; i++ ) {
            if ( !selector || jQuery.filter( selector, [ elem ] ).length ) {
                if ( !keepData && elem.nodeType === 1 ) {
                    jQuery.cleanData( elem.getElementsByTagName("*") );
                    jQuery.cleanData( [ elem ] );
                }

                if ( elem.parentNode ) {
                    elem.parentNode.removeChild( elem );
                }
            }
        }

        return this;
    },

И метод .cleanData, который он вызывает, который упоминает номер билета и якобы предотвращает эту ужасную утечку (согласно одному из комментариев):

cleanData: function( elems ) {
        var data, id, cache = jQuery.cache, internalKey = jQuery.expando, special = jQuery.event.special,
            deleteExpando = jQuery.support.deleteExpando;

        for ( var i = 0, elem; (elem = elems[i]) != null; i++ ) {
            if ( elem.nodeName && jQuery.noData[elem.nodeName.toLowerCase()] ) {
                continue;
            }

            id = elem[ jQuery.expando ];

            if ( id ) {
                data = cache[ id ] && cache[ id ][ internalKey ];

                if ( data && data.events ) {
                    for ( var type in data.events ) {
                        if ( special[ type ] ) {
                            jQuery.event.remove( elem, type );

                        // This is a shortcut to avoid jQuery.event.remove overhead
                        } else {
                            jQuery.removeEvent( elem, type, data.handle );
                        }
                    }

                    // Null the DOM reference to avoid IE6/7/8 leak (#7054)
                    if ( data.handle ) {
                        data.handle.elem = null;
                    }
                }

                if ( deleteExpando ) {
                    delete elem[ jQuery.expando ];

                } else if ( elem.removeAttribute ) {
                    elem.removeAttribute( jQuery.expando );
                }

                delete cache[ id ];
            }
        }
    }

И вот билет, упомянутый в комментарии. Видимо, это было исправлено восемь месяцев назад:

http://bugs.jquery.com/ticket/7054#comment:10

Согласно Дэйву Метвину, решение, похоже, состоит в том, чтобы убедиться, что элемент DOM-элемента ref в обработчике события удален cleanData, чтобы избежать утечки памяти IE6/7/8.

Другими словами, установите ссылки на элементы DOM в обработчиках событий на null, в противном случае некоторые удивительные браузеры, не упоминая какие-либо имена, кашель IE кашлят, будет утечка памяти.

discardElement (из вашей ссылки) вставляет элемент в контейнер и затем опустошает контейнер, тем самым сводя на нет любые ссылки на этот элемент.

С учетом этого я предлагаю обновить jQuery. Статья, на которую вы указываете, относится к 2009 году, а два года примерно эквивалентна времени разработки jQuery в четыреста миллионов человеко-часов.

Наконец, вот некоторые интересные (и смехотворно длинные) показания об утечках в Internet Explorer:

Понимание и устранение шаблонов утечки Internet Explorer

Ответ 2

Я собираюсь предположить, что он похож на сборку мусора .net, поскольку он полагается на объекты Pinned в куче.

IE обрабатывает родительский элемент удаляемого объекта, как штырь, и не очищает удаленный объект должным образом.

Акт перемещения удаленного элемента в этот сгенерированный контейнер gc в основном удаляет булавку, потому что IE знает, что ничего не полагается на этот контейнер.

В любом случае, мое чувство кишки.