4 вида утечек памяти в JavaScript и как с ними бороться

[tiagat]

Спасибо за статью! Как раз вовремя.

[tiagat]

Что я не так сказал?

[Buscando]

Отличная статья, спасибо!

[Miwwa]

Самая полная и подробная статья про утечки памяти в JS, которую я видел. Огромное спасибо

[MattLe]

Отличная статья, большое спасибо!!!

[baldr]

Может ли кто-то дать ссылки или советы по поиску утечек в проекте с jQuery и событиями?
Я стараюсь работать, в основном, с бэкендом и на фронтенд не очень много сил трачу. Использую CoffeeScript+jQuery и некоторые плагины.
Вижу что в FF память течет — после перезагрузки страницы объем занятой памяти (плагин TabMemoryUsage) увеличивается стабильно на 3Мб. Профилирование javascript — не такая простая задача, как для Python — покопался в отладочных инструментах, но не все так очевидно как на примере из статьи.
Есть еще какие-то рекомендации?

[vanxant]

Краткое содержание, если опустить специально сконструированные хаки для js:
1. «use strict», Luke
2. Не быдлокодь

[barkadron]

Огромное спасибо, очень интересно!
Остался вопрос — сборщик мусора запускает алгоритм поиска и пометки недостижимых ссылок с какой-то периодичностью или по какому-то событию? Как часто это происходит, примерно?

[aalexeev]

Как указано в статье, работа сборщика недетерменирована. Т.е. мы не можем запустить его из JS или угадать, когда он сработает.

[barkadron]

Да, это я понимаю, но ведь есть какой-то алгоритм его запуска.
В статье сказано, что сборка мусора может не произойти, если все недостижимые ссылки будут найдены, но не происходит последующих выделений памяти — тут всё понятно. А как на счёт самого процесса поиска недостижимых ссылок — как часто это происходит? При новых выделениях памяти, через фиксированный интервал времени или как-то иначе?

[barkadron]

Нашёл статью http://v8project.blogspot.ru/2015/08/getting-garbage-collection-for-free.html
Грубо говоря, выходит, что у Хрома есть 16.6ms-циклы, и если он успевает сделать приоритетные задачи до окончания итерации, то остаток времени расходуется на низко-приоритетные задачи, включая и сборку мусора.

[f0rk]

В Chrome есть флажек --js-flags="--expose-gc", с ним в коде можно вызывать gc(), бывает полезно при ловле утечек.

[Sky-Fox]

Большое спасибо за статью!
Не так часто бывает что после прочтения, практически не остается вопросов, а для тех что возникли, уже и ссылки в статье подготовленны.

[bkzhn]

Хорошая статья.

[zeezdev]

Спасибо за статью!
Сказанное о каллбеках на примере рекомендуемого к использованию addEventListener справедливо так же и для attachEvent / detachEvent?
Как правильно поступать перед удалением объекта при простом «навешивании» обработчиков в стиле:

element.onclick = function() { alert(1); }

Делать

element.onclick = null;

[kovalexius]

var theThing = null;
var replaceThing = function () 
{
  var originalThing = theThing;
  var unused = function ()     // Данная лямбда ссылается на ссылку originalThing,
                               // однако на данную лямбду окромя ссылки unusued 
                               // ссылок нет. 
  {
    if (originalThing)
      console.log("hi");
  };
  theThing = // переинициализируем ссылку theThing нижеописанной лямбдой, 
             // которая ни на что не ссылается. На текущую лямбду будет ссылаться 
             // ссылка theThing, на предыдущую лямбду в данный 
             // момент ссылается только лишь ссылка originalThing, верно?
  {
    longStr: new Array(1000000).join('*'),
    someMethod: function () 
    {
      console.log(someMessage);
    }
  };
};     // смело грохаем лямбду по ссылке unused, затем
       // грохаем лямбду originalThing (gc с подсчетом ссылок)

setInterval(replaceThing, 1000);

Так в чем проблема? При выходе из области видимости лямбды replaceThing мы можем смело грохнуть объект (лямбду) расположенную по ссылке unused, тем самым разрешив разрушение объекта (лямбды) расположенной по ссылке originalThing.