Динамично загруженный JavaScript может быть разгружен?

Race conditions.

These are one of the few things that still sends a shiver down my spine when it comes up in debugging (or in the issue tracker). Inherently horrible to debug, and extremely easy to create. The three most common causes of bugs in my C++ software have been race conditions, reliance on uninitialised memory, and reliance on static constructor order.

And if you don't know what race conditions are, chances are they're the cause of your instability ;)

Если вы не передаете никаких ссылок на то, что находится внутри замыкания, ни на что за его пределами, тогда window.MyModule будет единственной ссылкой на это замыкание и его контекст выполнения. Чтобы выгрузить его:

try {
    delete window.MyModule;
}
catch (e) {
    // Work around IE bug that doesn't allow `delete` on `window` properties
    window.MyModule = undefined;
}

Это сообщает среде JavaScript, что вы больше не используете это свойство, и делает все, на что оно ссылается, доступным для сборки мусора. Когда и произойдет ли этот сбор, очевидно, зависит от реализации.

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

window.MyModule = (function() {

    alert('This happens the moment the module is loaded.');

    function foo() {
        bar();
    }

    function bar() {
    }

    function destructor() {
        // Unhook event handlers here
    }

    return destructor;
})();

Отключение:

if (window.MyModule) {
    try {
        window.MyModule();
    }
    catch (e) {
    }
    try {
        delete window.MyModule;
    }
    catch (e) {
        // Work around IE bug that doesn't allow `delete` on `window` properties
        window.MyModule = undefined;
    }
}

Если вас беспокоят утечки памяти, вам нужно убедиться, что в коде, который вы хотите удалить, нет обработчиков событий, ссылающихся на все еще существующее дерево dom.

Это может быть что вам нужно вести список всех обработчиков событий, добавленных вашим кодом, и перед выгрузкой пройтись по ним и удалить обработчики событий.

Я никогда не делал этого таким образом, я всегда беспокоюсь, когда удаляю узлы, которые все еще ссылка.

Вот хорошая статья об утечках памяти в javascript: http://javascript.crockford.com/memory/leak.html

Если вы сохраняете оцененный код в пространствах имен, например:

var MYAPP = {
    myFunc: function(a) { ... }
}

«Освобождение» всего этого должно быть таким же простым, как установка MYPP на какое-то случайное значение, аля

MYAPP = 1

Это действительно зависит от того, что нет других средств ссылки на переменную, что нетривиально

Как насчет загрузки файлов JS в iframe? Затем (теоретически, никогда не тестировал это сам) вы можете удалить iframe из DOM и удалить «память», которую он использует.

Я думаю ... или надеюсь ...

У интерпретаторов JavaScript есть сборщики мусора. Другими словами, если вы ни на что не ссылаетесь, они не будут храниться.

Одна из причин, по которой JSON хорошо использовать с функцией обратного вызова (JSONP).

пример, если ваш HTTP-ответ для каждого JS:

callback({status: '1', resp: [resp here..]});

И если callback () не создает ссылку на объект JSON, переданный в качестве аргумента, он будет удален после завершения функции.

Если вам действительно нужно сделать ссылку, то вам, вероятно, по какой-то причине понадобятся эти данные - иначе вы бы / не должны были ссылаться на них в первую очередь.

Методы, упомянутые для объектов пространства имен, просто создают ссылку, которая будет сохраняться до тех пор, пока счетчик ссылок не станет равным 0. Другими словами, вы должны отслеживать каждую ссылку и удалять ее позже, что может быть сложно, когда у вас есть замыкания и ссылки из DOM. Всего одна ссылка сохранит объект в памяти, а некоторые простые операции могут создавать ссылки без вашего ведома.